Cluster Level Administrator access required for MAS Install – In both customer environments, there is a separate of duty where as that level of access is not given out to only a select # of people.

As a workaround can we seperate out the admin processes into a different ansible role. This can then be run by an admin with higher level access to the OCP cluster. Once done, the MAS install ( which does not need admin rights) can be run by whoever is doing the Maximo install.

Each step/stage of an install is already a seperate ansible role that can be used in isolation, as part of a playbook, via a Tekton task/pipeline, or via the MAS CLI. The statements here are very general, but assuming I've not misunderstood the intent; in any organization that wants to divide roles to the level of who creates the namespaces, who creates the subscription, who creates the operand, etc etc there's nothing in MAS's design that prevents them doing that today in the same way they do with any other operator-based application they manage. Most (all) of our autoamtion and documentation efforts thus far have been targeting less experienced/advanced use-cases where the goal is to provide as light a touch with OpenShift as possible to the Maximo customer, and perhaps as a result leaves the impression that this is the only way MAS can be managed.

Giving cluster admin rights to any containerized application exposes all the other application's running on that cluster as well as cluster level secrets and is bad practice and unacceptable

We don't give cluster admin rights to the application, or use cluster-level secrets. A limited ClusterRole is granted to the MAS Core which is what allows a MAS admin to install/manage MAS applications via the MAS admin dashboard without any access to OCP itself. It can only operate within the confines of the MAS namespaces and the MAS applications however. Without this role much of the MAS admin-dashboard (and admin APIs can not function)

We should be able to run any new containerized application in an existing cluster alongside other applications (isolated from each other)

We can, and do, support this. MAS operates across a group of namespaces and will not touch other namespaces and can happily co-exist with workloads in other namespaces.

My take away from this idea and other discussions in this area is that there are various actions we should be putting on the take to undertake to address this idea:

1. Improving the documentation around what permissions are needed to run the MAS install, update, upgrade CLI commands

2. Potentially also improving the documentation around what permissions are needed to run the various MAS ansible roles

3. Improving the documentation around what exactly the MAS CLI-based install/update/upgrade does to a cluster (for MAS and it's dependencies)

4. Explicitly defining the permissions for the MAS pipelines service account instead of taking the easy option of setting that service account to use the cluster-admin role so it's more explicit what the tekton pipeline is being given powers to do and the installer respects the same "least privilege required" design as the product it's installing does.

5. Providing a "disable MAS admin powers" option within the product itself such that MAS no longer has cluster admin powers, at the cost that the MAS admin-dashboard can not be used. This will allow advanced users who wish to work with MAS directly via OpenShift/Kubernetes APIs to do so without having to set up the "delegated MAS adminstration" part of the product that is geared towards customers that don't want to work with MAS at the OpenShift layer. When this option is enabled MAS Core would have no cluster admin powers, and the APIs and admin dashboard would offer greatly reduced capability with even limited ability to show what Maximo applications are installed/configured in the cluster, let alone modify what is installed or the configuration thereof (which would tie in nicely with the support for GitOps Managed MAS that we are working on too).

Giving cluster admin rights to any containerized application exposes all the other application's running on that cluster as well as cluster level secrets and is bad practice and unacceptable. We should be able to run any new containerized application in an existing cluster alongside other applications (isolated from each other). This is the spirit of an OpenShift cluster. In our case, giving cluster admin is a no-go. We would be forced to stand up isolated clusters just for Maximo, and have the additional hardware and on-going maintenance expenses of maintaining them long term.

I have another client that wants to install in a shared cluster and is coming up against this having Admin rights.

As a workaround can we seperate out the admin processes into a different ansible role. This can then be run by an admin with higher level access to the OCP cluster. Once done, the MAS install ( which does not need admin rights) can be run by whoever is doing the Maximo install.

With OCP becoming more prevalent in the marketspace and as MAS matures we are going to have to address this

Thank you for your feedback. Our team has evaluated your idea.

For installation of a new MAS instance, there is an unavoidable need for Cluster Level Administrator access because we need to control cluster level resources.

For MAS application install and upgrade, cluster access is not required as apps can be installed from the MAS admin dashboard.

For Catalog updates, cluster access is required as this impacts the whole catalog (all MAS instances on the cluster).

While we are happy to review and update or clarify our documentation around this, we don't intend to make any fundamental changes to this approach in the foreseeable future.

Thank you again for your feedback.