Chapter 5. Setting up HawtIO on OpenShift 4 On OpenShift 4.x, setting up HawtIO involves installing and deploying it. The preferred mechanism for this installation is using the HawtIO Operator available from the OperatorHub (see Section 5.1, "Installing and deploying HawtIO on OpenShift 4.x by using the OperatorHub"). Optionally, you can customize role-based access control (RBAC) for HawtIO as described in Section 2.3, "Role-based access control for HawtIO on OpenShift 4.x". 5.1. Installing and deploying HawtIO on OpenShift 4 by using the OperatorHub The HawtIO Operator is provided in the OpenShift OperatorHub for the installation of HawtIO. To deploy HawtIO you will have to deploy an instance of the installed operator as well as a HawtIO Custom Resource (CR). To install and deploy HawtIO: Log in to the OpenShift console in the web browser as a user with cluster admin access. Click Operators and then click OperatorHub . In the search field window, type HawtIO to filter the list of operators. Click HawtIO Operator . In the HawtIO Operator install window, click Install . The Create Operator Subscription form opens: For Update Channel , select stable-v1 . For Installation Mode , accept the default (a specific namespace on the cluster). Note This mode determines what namespaces the operator will monitor for HawtIO CRs. This is different to what namespaces HawtIO will monitor when it is fully deployed. The latter can be configured via the HawtIO CR. For Installed Namespace , select the namespace in which you want to install HawtIO Operator. For the Update Approval , select Automatic or Manual to configure how OpenShift handles updates to HawtIO Operator. If the Automatic updates option is selected and a new version of HawtIO Operator is available, the OpenShift Operator Lifecycle Manager (OLM) automatically upgrades the running instance of HawtIO without human intervention; If the Manual updates option is selected and a newer version of an Operator is available, the OLM only creates an update request. A Cluster Administrator must then manually approve the update request to have HawtIO Operator updated to the new version. Click Install and OpenShift installs HawtIO Operator into the current namespace. To verify the installation, click Operators and then click Installed Operators . HawtIO should be visible in the list of operators. To deploy HawtIO by using the OpenShift web console: In the list of Installed Operators , under the Name column, click HawtIO Operator . On the Operator Details page under Provided APIs , click Create HawtIO . Accept the configuration default values or optionally edit them. For Replicas , to increase HawtIO performance (for example, in a high availability environment), the number of pods allocated to HawtIO can be increased; For RBAC (role-based access control), only specify a value in the Config Map field if you want to customize the default RBAC behaviour and if the ConfigMap file already exists in the namespace in which you installed HawtIO Operator For Nginx , see Performance tuning for HawtIO Operator installation For Type , specify either: Cluster : for HawtIO to monitor all namespaces on the OpenShift cluster for any HawtIO-enabled applications; Namespace : for HawtIO to monitor only the HawtIO-enabled applications that have been deployed in the same namespace. Click Create . The HawtIO Operator Details page opens and shows the status of the deployment. To open HawtIO : For a namespace deployment: In the OpenShift web console, open the project in which the HawtIO operator is installed, and then select Overview . In the Project Overview page, scroll down to the Launcher section and click the HawtIO link. For a cluster deployment, in the OpenShift web console's title bar, click the grid icon. In the popup menu, under Red Hat Applications , click the HawtIO URL link. Log into HawtIO. An Authorize Access page opens in the browser listing the required permissions. Click Allow selected permissions . HawtIO opens in the browser and shows any HawtIO-enabled application pods that are authorized for access. Click Connect to view the monitored application. A new browser window opens showing the application in HawtIO. 5.2. Role-based access control for HawtIO on OpenShift 4 HawtIO offers role-based access control (RBAC) that infers access according to the user authorization provided by OpenShift. In HawtIO, RBAC determines a user's ability to perform MBean operations on a pod. For information on OpenShift authorization, see the Using RBAC to define and apply permissions section of the OpenShift documentation. Role-based access is enabled by default when you use the Operator to install HawtIO on OpenShift. HawtIO RBAC leverages the user's verb access on a pod resource in OpenShift to determine the user's access to a pod's MBean operations in HawtIO. By default, there are two user roles for HawtIO: admin : if a user can update a pod in OpenShift, then the user is conferred the admin role for HawtIO. The user can perform write MBean operations in HawtIO for the pod. viewer : if a user can get a pod in OpenShift, then the user is conferred the viewer role for HawtIO. The user can perform read-only MBean operations in HawtIO for the pod. 5.2.1. Determining access roles for HawtIO on OpenShift 4 HawtIO role-based access control is inferred from a user's OpenShift permissions for a pod. To determine HawtIO access role granted to a particular user, obtain the OpenShift permissions granted to the user for a pod. Prerequisites : The user's name The pod's name Procedure : To determine whether a user has HawtIO admin role for the pod, run the following command to see whether the user can update the pod on OpenShift: oc auth can-i update pods/<pod> --as <user> If the response is yes, the user has the admin role for the pod. The user can perform write operations in HawtIO for the pod. To determine whether a user has HawtIO viewer role for the pod, run the following command to see whether the user can get a pod on OpenShift: oc auth can-i get pods/<pod> --as <user> If the response is yes, the user has the viewer role for the pod. The user can perform read-only operations in HawtIO for the pod. Depending on the context, HawtIO prevents the user with the viewer role from performing a write MBean operation, by disabling an option or by displaying an operation not allowed for this user message when the user attempts a write MBean operation. If the response is no, the user is not bound to any HawtIO roles and the user cannot view the pod in HawtIO. 5.2.2. Customizing role-based access to HawtIO on OpenShift 4 If you use the OperatorHub to install HawtIO, role-based access control (RBAC) is enabled by default. To customize HawtIO RBAC behaviour, before deployment of HawtIO, a ConfigMap resource (that defines the custom RBAC behaviour) must be provided. The name of this ConfigMap should be entered in the rbac configuration section of the HawtIO Custom Resource (CR). The custom ConfigMap resource must be added in the same namespace in which the HawtIO Operator has been installed. Prerequisite : The HawtIO Operator has been installed from the OperatorHub. Procedure : To customize HawtIO RBAC roles: Create an RBAC ConfigMap: Make sure the current OpenShift project is the project to which you want to install HawtIO. For example, to install HawtIO in the hawtio-test project, run this command: oc project hawtio-test Create a HawtIO RBAC ConfigMap file from the template, and run this command: oc process -f https://raw.githubusercontent.com/hawtio/hawtio-online/2.x/docker/ACL.yaml -p APP_NAME=custom-hawtio | oc create -f - Edit the new custom ConfigMap, using the command: oc edit ConfigMap custom-hawtio-rbac By saving the edits, the ConfigMap resource will be updated Create a new HawtIO CR, as described above, and edit the rbac section by adding the name of the new ConfigMap under the property configMap . Click Create . The operator should deploy a new version of HawtIO making use of the custom ConfigMap 5.3. Migrating from Fuse Console The version of the HawtIO Custom Resource Definition (CRD) has been upgraded in HawtIO from v1alpha1 to v1 and contains non-backwards compatible changes. Therefore, since the CRD is cluster-wide, this will have a detrimental impact on existing installations of Fuse Console if HawtIO is subsequently installed on the same cluster. Users are advised at this time to uninstall all versions of Fuse Console before proceeding with the installation of HawtIO. Users wishing to migrate their existing HawtIO Custom Resources to HawtIO, can store the resource configuration in a file and re-apply them once the HawtIO Operator has been installed. On re-applying, the CR will be upgraded to the version v1 automatically. An important change in the new specification is that the version property can no longer be specified in the CR as the version is provided as an internal constant of the operator itself. 5.4. Upgrading HawtIO on OpenShift 4 Red Hat OpenShift 4.x handles updates to operators, including HawtIO operators. For more information see the Operators OpenShift documentation . In turn, the operator updates will trigger application upgrades, depending on how the application is configured. 5.5. Tuning the performance of HawtIO on OpenShift 4 By default, HawtIO uses the following Nginx settings: clientBodyBufferSize: 256k proxyBuffers: 16 128k subrequestOutputBufferSize: 10m Note For descriptions of these settings, see the Nginx documentation . To tune the performance of HawtIO, you can set any of the clientBodyBufferSize , proxyBuffers , and subrequestOutputBufferSize environment variables. For example, if you are using HawtIO to monitor numerous pods and routes (for instance, 100 routes in total), you can resolve a loading timeout issue by setting HawtIO's subrequestOutputBufferSize environment variable between 60m to 100m . 5.5.1. Performance tuning for HawtIO Operator installation On Openshift 4.x, you can set the Nginx performance tuning environment variables before or after you deploy HawtIO. If you do so afterwards, OpenShift redeploys HawtIO. Prerequisite : You must have cluster admin access to the OpenShift cluster. Procedure : You can set the environment variables before or after you deploy HawtIO. To set the environment variables before deploying HawtIO : In the OpenShift web console, in a project that has HawtIO Operator installed, select Operators> Installed Operators> HawtIO Operator . Click the HawtIO tab, and then click Create HawtIO . On the Create HawtIO page, in the Form view , scroll down to the Config> Nginx section. Expand the Nginx section and then set the environment variables. For example: clientBodyBufferSize: 256k proxyBuffers: 16 128k subrequestOutputBufferSize: 100m Click Create to deploy HawtIO. After the deployment completes, open the Deployments> HawtIO-console page, and then click Environment to verify that the environment variables are in the list. To set the environment variables after you deploy HawtIO : In the OpenShift web console, open the project in which HawtIO is deployed. Select Operators> Installed Operators> HawtIO Operator . Click the HawtIO tab, and then click HawtIO . Select Actions> Edit HawtIO . In the Editor window, scroll down to the spec section. Under the spec section, add a new nginx section and specify one or more environment variables, for example: apiVersion: hawt.io/v1 kind: Hawtio metadata: name: hawtio-console spec: type: Namespace nginx: clientBodyBufferSize: 256k proxyBuffers: 16 128k subrequestOutputBufferSize: 100m Click Save . OpenShift redeploys HawtIO. After the redeployment completes, open the Workloads> Deployments> HawtIO-console page, and then click Environment to see the environment variables in the list. 5.5.2. Performance tuning for viewing applications on HawtIO Enhanced performance tuning capability of HawtIO allows viewing of the applications with a large number of MBeans. To use this capability perform the following steps. Prerequisite : You must have cluster admin access to the OpenShift cluster. Procedure : Increase the memory limit for the applications. To increase the memory limits after deploying HawtIO : In the OpenShift web console, open the project in which HawtIO is deployed. Select Operators> Installed Operators> HawtIO Operator . Click the HawtIO tab, and then click HawtIO . Select Actions> Edit HawtIO . In the Editor window, scroll down to the spec.resources section. Update the values for both requests and limits to preferred amounts Click Save HawtIO should re-deploy using the new resource specification.

Commands:
auth can-i update pods/<pod> --as <user>
auth can-i get pods/<pod> --as <user>
project hawtio-test
process -f https://raw.githubusercontent.com/hawtio/hawtio-online/2.x/docker/ACL.yaml -p APP_NAME=custom-hawtio | oc create -f -
edit ConfigMap custom-hawtio-rbac
apiVersion: hawt.io/v1 kind: Hawtio metadata: name: hawtio-console spec: type: Namespace nginx: clientBodyBufferSize: 256k proxyBuffers: 16 128k subrequestOutputBufferSize: 100m