Authors: Leela Chitta, Arjun Dev & Kevin Trinh

Overview:

As enterprises increasingly adopt Kubernetes and OpenShift for their business automation needs, security and compliance have become paramount concerns. One of the most frequent questions from customers and security teams is: "Why do operators need cluster-wide permissions?" In response to this feedback, IBM Cloud Pak for Business Automation (CP4BA) has undertaken a significant initiative to remove cluster-level Role-Based Access Control (RBAC) permissions from operators, transitioning to namespace-scoped permissions instead.

This blog explains the motivation behind this change, what it means for administrators, and how it simplifies security audits while maintaining full functionality across the platform.

The Challenge: Cluster-Wide Permissions

Traditionally, many Kubernetes operators—including those in CP4BA—required ClusterRole permissions to function. These cluster-wide permissions allowed operators to access resources across all namespaces, which raised several concerns:

Security Audits: Organizations with strict security policies found it challenging to justify why operators needed access beyond their deployment namespace

Compliance Requirements: Many industries require clear permission boundaries and the principle of least privilege

Multi-Tenancy: In shared cluster environments, cluster-wide permissions created potential security risks

The Solution: Namespace-Scoped Permissions

Starting with CP4BA 25.0.1, we've systematically removed ClusterRole permissions from operators across the platform, replacing them with namespace-scoped Role permissions. This change aligns with Kubernetes security best practices and the principle of least privilege.

Benefits

• Enhanced Security: Operators can only access resources within their designated namespace, reducing the attack surface

• Simplified Audits: Security teams can easily verify that permissions are scoped appropriately

• Better Multi-Tenancy: Multiple deployments can coexist in the same cluster with clear permission boundaries

• Compliance-Friendly: Meets strict regulatory requirements for permission scoping

Operators Updated for CP4BA

The following operators have been updated to use namespace-scoped permissions in the 25.0.1 release:

1. IBM Cloud Pak for Business Automation (CP4BA) multi-pattern - CP4BA Main operator

2. IBM FileNet Content Manager - Content capabilities

3. IBM Workflow Process Service (WfPS) Operator - Workflow runtime services

4. IBM Process Federation Server (PFS) Operator - Federated process management

5. IBM Workflow Operator - Core workflow capabilities

6. IBM Automation Decision Services

7. IBM Operational Decision Manager

8. IBM Document Processing Engine

9. IBM Business Teams Service

10. IBM Insights Engine - BAI

Technical Implementation

The transition involved a comprehensive testing and validation process:

• Permission Analysis: We identified all cluster-level permissions used by each operator

• Namespace Migration: Permissions were moved from ClusterRole to Role definitions where possible

• Code Updates: Operator code was modified to work within namespace boundaries

• Validation: Extensive testing ensured all functionality remained intact

Example: StorageClass Access

One specific challenge we addressed was accessing StorageClass resources, which are cluster-scoped in Kubernetes. Instead of requiring cluster-wide permissions to watch StorageClass resources, we modified the operators to:

Read storage class names from the ICP4ACluster CR's storage_configuration section

Create minimal StorageClass objects without making API calls to the Kubernetes API server

Fall back to common default names if no storage class is specified

This approach prevents the controller-runtime from setting up watches for StorageClass resources, eliminating the need for cluster-wide permissions.

What This Means for Administrators

Installation

• The installation process remains unchanged. Administrators continue to use the same deployment scripts and procedures. The permission changes are transparent and require no additional configuration.

Security Audits

• When conducting security audits, administrators can now demonstrate:

• • Clear permission boundaries at the namespace level

  • Minimal cluster-level access (only for specific operators that require it)

  • Compliance with the principle of least privilege

Existing Deployments

• Not supported

Real-World Impact

During our testing and validation, we encountered and resolved various permission-related issues. For example, when accessing CommonService custom resources, we initially encountered HTTP 403 errors:

{
  "error": {
    "code": 403,
    "reason": "Forbidden",
    "message": "User \"system:serviceaccount:namespace:operator\" cannot get resource \"commonservices\""
  }
}

By systematically identifying these scenarios and adding the appropriate namespace-scoped permissions, we ensured seamless operation while maintaining security boundaries.

Conclusion

The transition to namespace-scoped permissions in IBM Cloud Pak for Business Automation demonstrates our commitment to security, compliance, and customer feedback. By removing cluster-level access while maintaining full functionality, we've made it easier for organizations to deploy in security-conscious environments.

This change simplifies security audits, improves multi-tenancy support, and aligns with Kubernetes best practices—all without requiring changes to your deployment procedures.

For more information about CP4BA security features and deployment best practices, visit the IBM Cloud Pak for Business Automation documentation.

Note: This capability is available starting with IBM Cloud Pak for Business Automation 25.0.1