Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HAL on OpenShift #708

Merged
merged 8 commits into from
Dec 19, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions _posts/2024-12-18-Management-Console-on-OpenShift.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
---
layout: post
title: "Using the management console on OpenShift"
date: 2024-12-18
tags: hal management console openshift
author: hpehl
description: How to use the management console for WildFly instances running on OpenShift.
---

In this blog post I'd like to show how you can use the management console (aka https://hal.github.io[HAL]) for WildFly instances running on OpenShift.

== Prerequisites

The console is an integral part of WildFly and is activated by default when running on-premise. For instances running on OpenShift, the console is not available by default, though. To use the console on OpenShift, you need a WildFly image that meets the following requirements:

* Management user: +
The management console is protected by default and requires a management user added with the `add-user.sh` script.
* Public route to the management interface: +
The management interface has to be publicly available from the outside.
* Allowed origin: +
The console uses the https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API[fetch API] to talk to the management interface of a running WildFly instance. In an OpenShift environment, the origins of the public route and the management interface itself are different. That's why we need to tell WildFly that it is ok to make requests to the management interface from another origin (see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS[CORS policies] for more details).

You can build such an image on your own based on the official WildFly images available at https://quay.io/repository/wildfly/wildfly[quay.io/wildfly/wildfly] (see "Extending the image"). Another way is to use the pre-built images from https://quay.io/repository/halconsole/wildfly[quay.io/halconsole/wildfly]. These images are mainly meant for HAL development and testing but already meet these requirements, which makes them suitable for our use case. In particular the images add a management user `admin:admin` and have a list of preconfigured allowed origins.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a WARNING admonition block saying this preconfigured admin:admin setup is for development purposes or something? I'd be concerned if people start running this in production and relying only on allowed-origins to control access.

WARNING: The additions in the https://quay.io/repository/halconsole/wildfly[quay.io/halconsole/wildfly] images are *only* meant for *development and testing* purposes. Under *no circumstances* must this be *used in production*! Do not rely on the management user `admin:admin` or the preconfigured allowed origins.

To add the allowed origin for the public route, we make use of the https://github.com/jmesnil/kubectl-jboss-cli/[`jboss-cli`] `kubectl` plugin. This plugin makes it straightforward to connect to a WildFly instance running on OpenShift and execute CLI commands. Please visit https://github.com/jmesnil/kubectl-jboss-cli/ to find out how to install and use the plugin.

== Instructions

The steps below assume you have access to an OpenShift cluster and installed `kubectl` and the `jboss-cli` plugin.

. Create application
+
[source,shell]
----
oc new-app quay.io/halconsole/wildfly
oc create route edge --service wildfly --port 9990
----

. Add allowed origin
+
Use `oc get pods` to find the name of the pod to connect to and `oc get routes` to get the hostname of the public route to the management interface.
+
[source,shell]
----
kubectl jboss-cli -p <pod>
----
+
Login using `admin:admin` and execute these CLI commands:
+
[source,shell]
----
/core-service=management/management-interface=http-interface:list-add(name=allowed-origins,value=https://<hostname>)
reload
exit
----

. Open the management console at `+https://<hostname>+` and login using `admin:admin`.

=== Online version of the management console

As an alternative to adding the allowed origin, you can also use the online version of the management console available at https://hal.github.io/console. This URL ships the latest version of the management console.

NOTE: The management console is a single-page application (https://en.wikipedia.org/wiki/Single-page_application[SPA]) without any server side dependencies. As such, it can run on its own and connect to an arbitrary management interface. The online version of the console makes use of this fact. See https://hal.github.io/documentation/get-started/#standalone-mode for more details.

. Create the application as above and find the hostname of the public route using `oc get routes`.
. Open https://hal.github.io/console
. Add a management interface to the public route:
+
Give an arbitrary name, select *https* as a scheme, enter the hostname of the public route _without_ https and port *80*:
+
image::hal/add-management-interface.png[Add management interface]
. Click *Add* and then *Connect*
. Login using `admin:admin`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I did this to connect to the deployment created with ocnew-app quay.io/halconsole/wildfly, I got the error:

Status 401 - Unauthorized.

The management console could not be loaded.

If you changed your access control provider to RBAC, make sure that your configuration has current user mapped to one of the RBAC roles, preferably with at least one in the Administrator or SuperUser role.

If you have started with one of the standard xml configurations shipped with WildFly, the "$local" user should be mapped to the "SuperUser" role and the "local" authentication scheme should be enabled. This should allow a user running the CLI on the same system as the WildFly process to have full administrative permissions. Remote CLI users and web-based admin console users will have no permissions.

You should map at least one user besides "$local". Try to use CLI or shut the installation down and edit the xml configuration.

That seems weird as I was able to connect as admin:admin on the local HAL console.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does a browser refresh or private mode help?

Copy link
Contributor Author

@hpehl hpehl Dec 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tried to reproduce that. This is what I did:

  1. Create the app
oc new-app quay.io/halconsole/wildfly
oc create route edge --service wildfly --port 9990
  1. Open https://hal.github.io/console
  2. Add the management interface. Please make sure to use port 80.
  3. Connect and login using admin:admin

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird, it still fails for me.

I thought that was due to the /core-service=management/management-interface=http-interface:list-add(name=allowed-origins,value=https://<hostname>) on my deployment but even with a fresh deployment it fails (using Chrome incognito mode)


== Things to keep in mind

Please note that the above instructions are just a workaround to access the OpenShift management console as long as there is no more compatible, container-friendly way. In particular, the approach ignores some principles that should not be applied in a cloud environment:

* Changing the management configuration of a pod is an antipattern as it will not outlive a pod restart. At that point, you'll have to reconfigure the allowed origin.
* With a route, you are accessing pods behind a service. If your deployments have multiple pods, it's complex and hacky to access a specific pod or configure all pods.
* *Do not use* the https://quay.io/repository/halconsole/wildfly[quay.io/halconsole/wildfly] images *in production* under any circumstances. They contain preconfigured, insecure credentials and are meant only for development and testing purposes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add something about not using admin:admin in an insecure environment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

== Outlook

We're currently working on the https://github.com/hal/foundation[next-gen management console]. This version will also support a dedicated variant for OpenShift that will integrate with the OpenShift management console and addresses the limitations mentioned above. For more information you can watch the https://www.youtube.com/watch?v=Karu90yDIhs&t=571s[talk] on the next-gen management console from the last https://www.wildfly.org/conference/[WildFly mini conference], get the https://www.wildfly.org/assets/data/conference/202411_wmc_nextgen_console.pdf[slides] or reach out to us in the HAL Zulip https://wildfly.zulipchat.com/#narrow/channel/174373-hal[channel].
Binary file added assets/img/news/hal/add-management-interface.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.