Skip to Main Content
IBM Sustainability Software - Ideas Portal


This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on Sep 18, 2024

Request to support installation procedures beyond Ansible for Maximo Application Suite with consideration to segregation of duties and support to standard best practices in K8s.

executing the installation of all the operators (ibm-common-services, ibm-sls, mas-dro, mas-core, mas-manage, cert-manager) at one stretch, may not be possible. Hence, there should be an ability to break down the installation of operators one-by-one.

4. Similarly, due to segregation of duties, even namespace admins might not have access to all the APIs provided by the operators and to create instances/workspaces. RBAC policies might need to be defined in-order to gain access to the operator APIs and to create instances/services/workspace. So, installation procedure should also clearly dProblem Statement:

Maximo Application Suite installation has limitations of a single deployment tool- Ansible. While Ansible is a popular choice for automating installation, there are situations where organizations have their own cloud native powerful deployment tools and organizations should have ability to break free from the limitations of single deployment tool like Ansible.

Idea/Requirement:

1. Major OEMs will have their own cloud solutions/Open Shift platforms. Open Shift cluster will be managed by their infrastructure/engineering team. Application team may not/will not have cluster admin access to the Open Shift cluster, since there will be multiple applications/instances might be running under the same Open Shift cluster. Providing cluster admin access to the Open shift cluster creates risk of tampering other applications running under the same cluster. Hence, the pre-requisite of having cluster admin access as part of Ansible Playbook installation may not be a viable option. So, the installation procedure should be split into tasks which has to be executed by cluster admin and those that can be executed by namespace admins. Segregation of duties and access restrictions are key internal controls of every organization.

2. Though Ansible is robust automation deployment engine, not every organization might be using Ansible. In our case, we use Kustomize manifest with ArgoCD based deployment. So, installation procedure should not be restricted to just one deployment engine. Organizations should have ability to extrapolate the Kubernetes YAMLs and install MAS using their own deployment methodology.

3. Ability to install Operators individually should be provided. As mentioned earlier cluster admin access will not be available for the application team. Application team might have only namespace admin access. So, efine the RBAC policies/cluster role bindings /Certificate issuer policies with issuer details that might be needed in-order to gain access for the namespace admins/service accounts that calls/creates/updates the operator APIs/instances/workspaces/generate certificates etc.

4. Similarly, due to segregation of duties, even namespace admins might not have access to all the APIs provided by the operators and to create instances/workspaces. RBAC policies might need to be defined in-order to gain access to the operator APIs and to create instances/services/workspace. So, installation procedure should also clearly define the RBAC policies/cluster role bindings /Certificate issuer policies with issuer details that might be needed in-order to gain access for the namespace admins/service accounts that calls/creates/updates the operator APIs/instances/workspaces/generate certificates etc.

5. Every organization may not use automatic approval plans for the operators. So, steps to manually approve/upgrade the operators (with other deployment engine/tools) should be available. When primary operators are approved manually, then its secondary operators should also get approved automatically. In addition, following requirements should be considered:

a. All Operator/CRD MUST be installed explicitly.

b. NO Operator/CRD MUST install automatically install another Operators/CRD

c. All Operator/CRD MUST be pinned by to version i.e., no automatic mode.

d. NO wildcards in Kubernetes RBAC are allowed.

e. NO custom OpenShift would be allowed.

6. Following restrictions should also be taken into considerations, as they are standard best practices in K8s

a. Ability to install MAS on clusters where basic security policies are turned on.

b. Singleton is not typically allowed in most of the OpenShift Clusters.

c. Logs running as a root are generally not allowed.

d. Running anything other than restricted SCC is not allowed.

e. Sometimes OpenShift clusters do not have default storage classes, so we may have to be explicitly define if we want to use storage.

f. YAML & Kustomize via ArgoCD is one of GitOps model to support deployment other than Ansible.

a. Nested operators need to be explicitly declared (in most of the OpenShift environments, Operators do not have permissions to install nested operators per least privilege model)

g. Sometimes there are restrictions to make use of in built opnshift-image registry, so ability to store container images in other registries/artifacts should be considered.

h. All containers must run as non-root user.

i. Containers cannot run privileged.

j. Containers cannot mount host filesystems (No host Path mounts)

k. Containers cannot attach to host network.

l. All Kubernetes objects must define resource requests/limits.

m. All Kubernetes objects must define liveness and readiness probes.

n. All application logs must be written to STDOUT so it can be picked up by the platform logging stack.

o. Cross mounting persistent volumes will not be permitted.

p. Container (POD) IPs are ephemeral and should not be considered static or a source of identity (static IPs not supported)

Idea priority Medium
Needed By Quarter