MAS GitOps GitOps Ansible CLI
Edit on GitHub
Home Details MAS GitOps RBAC Configuration Important: When to Use This Directory Overview Kustomize-based RBAC Management Files and Folders Quick Start generate_rbac_overlays.py Permissions Included Permissions NOT Included (Require cluster_admin_role) Deployment Workflow Troubleshooting Maintenance References

MAS GitOps RBAC Configuration¤

The rbac directory in the repository contains namespace-scoped RBAC (Role-Based Access Control) configurations for MAS GitOps deployments. This documentation provides comprehensive guidance on configuring RBAC when deploying with limited privileges (cluster_admin_role=false and application_admin_role=true).

This directory contains namespace-scoped RBAC (Role-Based Access Control) configurations for MAS GitOps deployments when cluster_admin_role=false and application_admin_role=true.

Important: When to Use This Directory¤

The Kustomize-based RBAC in this directory is only required when using the pre-install repository for cluster prerequisites.

If you are using cluster_admin_role=true in a separate ArgoCD instance to deploy cluster-level resources, the 600-application-admin-rbac Helm chart will automatically create all necessary RBAC for the application_admin_role. In this scenario, you do not need to use the Kustomize configurations in this directory.

Overview¤

The MAS GitOps repository supports three deployment modes:

  1. Cluster Admin Mode (cluster_admin_role=true, application_admin_role=true): Full cluster-admin privileges for deploying all resources. This is the default behaviour, and is what is used when neither variable is defined.
  2. Cluster Admin Mode (cluster_admin_role=true, application_admin_role=false): Full cluster-admin privileges for deploying cluster level resources only, this includes subscriptions and operators, but not application level resources.
  3. Application Admin Mode (cluster_admin_role=false, application_admin_role=true): Limited privileges for deploying application-level resources only

This directory provides the RBAC configuration for Application Admin Mode using namespace-scoped Roles, which follows the principle of least privilege by restricting access to specific, predefined namespaces.

Kustomize-based RBAC Management¤

The kustomize/ directory provides a declarative, GitOps-friendly approach using Kustomize for managing namespace-scoped RBAC when using the pre-install repository.

Benefits: - Declarative configuration - Easy to version control and review - Composable overlays for different service accounts - Follows GitOps best practices

See kustomize/README.md for detailed usage and examples.

Files and Folders¤

  • exmaple/build-ouptut - Example output of the kustomize build rbac/kustomize/overlays/mas-argocd-argocd-application-controller command
  • exmaple/overlays - Example of an overlay that would be generated by the generate_rbac_overlays.py script. This would be placed in the overlays folder under kustomize/ directory normally.
  • kustomize/ - Kustomize-based RBAC management (base, components, overlays)
  • generate_rbac_overlays.py - Generator script for creating namespaced overlay directories under kustomize/

Quick Start¤

  1. Generate overlays for your MAS instances:

The --service-account flag is required. Use the name of the ArgoCD service account in your cluster — typically <argocd-namespace>-argocd-application-controller. In the exmaple below this is mas-argocd-argocd-application-controller

   # Generate overlays for a single instance (dev2 in this exmaple)
   ./rbac/generate_rbac_overlays.py \
       --service-account mas-argocd-argocd-application-controller dev2

   # Generate overlays for multiple instances (dev2, inst2 and inst3 in this exmaple)
   ./rbac/generate_rbac_overlays.py \
       --service-account mas-argocd-argocd-application-controller dev2 inst2 inst3

This creates namespace overlay directories under rbac/kustomize/overlays/mas-argocd-argocd-application-controller/ and updates the resources: list in the overlay kustomization.yaml automatically.

  1. Apply RBAC using Kustomize:
   kubectl apply -k rbac/kustomize/overlays/mas-argocd-argocd-application-controller
  1. Verify:
   kubectl get role,rolebinding -n mas-dev2-core
   kubectl get clusterrole,clusterrolebinding mas-application-admin-readonly
   kubectl describe role mas-application-admin -n mas-dev2-core

See kustomize/README.md for creating custom overlays and adding namespaces.

generate_rbac_overlays.py¤

generate_rbac_overlays.py generates the Kustomize overlay directories for one or more MAS instances. Because Kustomize has no native loop/iteration, a separate subdirectory is required per namespace; this script automates that process.

Usage¤

./rbac/generate_rbac_overlays.py <instance-id> [<instance-id> ...]

Options¤

Option Default Description
instances (required) One or more instance IDs (e.g. dev2 inst2)
--service-account (required) ArgoCD service account name (e.g. mas-argocd-argocd-application-controller)

Namespace patterns generated per instance¤

Pattern Example (dev2)
db2u-{inst} db2u-dev2
mas-{inst}-core mas-dev2-core
mas-{inst}-manage mas-dev2-manage
mas-{inst}-sls mas-dev2-sls
mas-{inst}-syncres mas-dev2-syncres
mas-{inst}-visualinspection mas-dev2-visualinspection

Permissions Included¤

Namespace-scoped Resources¤

The Role grants full permissions (create, delete, get, list, patch, update, watch) for:

Core Kubernetes Resources¤

  • ConfigMaps, Secrets, Services, ServiceAccounts
  • PersistentVolumeClaims
  • Pods (including logs and exec)
  • ResourceQuotas, LimitRanges

Workload Resources¤

  • Deployments, StatefulSets, DaemonSets, ReplicaSets
  • Jobs, CronJobs

RBAC Resources (namespace-scoped only)¤

  • Roles, RoleBindings

Networking Resources¤

  • NetworkPolicies, Ingresses
  • Routes (OpenShift)
  • Istio resources (DestinationRules, VirtualServices, Gateways, PeerAuthentications, AuthorizationPolicies)

Certificate Management¤

  • Cert-manager Certificates, CertificateRequests, Issuers

MAS Resources¤

  • Core: Suites, Workspaces
  • Config: AppCfg, BasCfg, IDPCfg, JdbcCfg, KafkaCfg, MongoCfg, ObjectStorageCfg, SlsCfg, SmtpCfg, WatsonStudioCfg
  • Addons: GenericAddons
  • SLS: LicenseServices

Database Resources¤

  • DB2U: Db2uInstances, Db2uClusters

Cloud Pak for Data Resources¤

  • Ibmcpds, WmlBases, WS, Spss, AnalyticsEngines

AI Service Resources¤

  • AIServiceApps, AIServiceTenants
  • OpenDataHub: DataScienceClusters, DSCInitializations

IBM Common Services¤

  • IBMLicensings, NamespaceScopes, OperandConfigs, OperandRegistries

Monitoring Resources¤

  • ServiceMonitors, PodMonitors, PrometheusRules

Cluster-scoped Resources (Read-only)¤

The ClusterRole grants read-only permissions (get, list, watch) for:

  • Namespaces, Nodes
  • StorageClasses
  • Operator resources (CatalogSources, ClusterServiceVersions, InstallPlans, Subscriptions, OperatorGroups)
  • CustomResourceDefinitions
  • ArgoCD Applications and ApplicationSets
  • OpenShift cluster configuration (ClusterVersions, Infrastructures, Networks)

Permissions NOT Included (Require cluster_admin_role)¤

The following resources require cluster_admin_role=true and are NOT included:

Cluster-scoped RBAC¤

  • ClusterRoles (create/update/delete)
  • ClusterRoleBindings (create/update/delete)

Security Resources¤

  • SecurityContextConstraints (SCC)
  • PodSecurityPolicies

Cluster Configuration¤

  • CustomResourceDefinitions (create/update/delete - read-only access provided)
  • MutatingWebhookConfigurations
  • ValidatingWebhookConfigurations
  • APIServices

Storage¤

  • StorageClasses (create/update/delete - read-only access provided)
  • CSIDrivers, CSINodes
  • VolumeAttachments

Operator Management¤

  • OperatorGroups (create/update/delete)
  • Subscriptions (create/update/delete - read-only access provided)
  • CatalogSources (create/update/delete - read-only access provided)

OpenShift Cluster Resources¤

  • ClusterOperators
  • Console resources
  • ImageContentSourcePolicy, ImageDigestMirrorSet, ImageTagMirrorSet
  • IngressControllers
  • Proxies, Schedulers

Cert-manager Cluster Resources¤

  • ClusterIssuers

Deployment Workflow¤

Prerequisites (Cluster Admin)¤

Before deploying with application_admin_role=true and cluster_admin_role=false, cluster administrators must do one of the following:

Deploy cluster-level applications with cluster_admin_role=true and application_admin_role=false set on the root application. This must be set in a different ArgoCD instance and root application to the application install. The ArgoCD application resources should be created in a different namespace/cluster to the application install to avoid conflicts.

When using this approach, the 600-application-admin-rbac Helm chart automatically creates all necessary RBAC for the application_admin_role. You do not need to use the Kustomize configurations in this directory.

There is no RBAC generated for the cluster_admin_role as this is expected to be the cluster-admin.

Option 2: Install using pre-install repository¤

An alternative for using ArgoCD for the cluster_admin_role is to use the kustomize available in the pre-install repo. This will setup all the resources that need cluster level privileges. The pre-install only offers a subset of the cluster level resources that are provided if using the cluster_admin_role in ArgoCD, but offers enough to be able to get majority of installations to complete.

When using the pre-install repository, you MUST use the Kustomize-based RBAC configurations in this directory to create the necessary namespace-scoped RBAC for the application_admin_role. Please see the pre-install repo for more details.

Application Deployment (Application Admin)¤

With prerequisites in place, application administrators can deploy:

  1. MAS Suite and Configurations
  2. Suite instances
  3. Workspace configurations
  4. Application configurations (JDBC, Kafka, Mongo, ObjectStorage, etc.)

  5. Databases

  6. DB2U instances
  7. Database schemas and users

  8. MAS Applications

  9. Manage, Monitor, Health, Predict, Optimizer, etc.
  10. Application-specific configurations

  11. AI Services

  12. AI Service instances
  13. Tenant configurations

all by setting the cluster_admin_role=falseand application_admin_role=true in the root application in the ArgoCD instance, and by creating the expected values files in the gitops repository that ArgoCD is watching. More details on how to create these value files can be found in the documentation https://ibm-mas.github.io/gitops/

Troubleshooting¤

Common Issues¤

Issue: Cannot create resources in namespace X - Cause: Role doesn't exist in namespace X - Solution: Add a namespace overlay for X in rbac/kustomize/overlays/<service-account-name>/ via the generate_rbac_overlays.py script and re-apply

Issue: Cannot read StorageClasses - Cause: Read-only ClusterRole not applied or not bound to service account - Solution: Apply the cluster-readonly component and verify ClusterRoleBinding exists

Maintenance¤

Removing Access from Namespaces¤

To remove access from specific namespaces:

  1. Delete the Role and RoleBinding from those namespaces: bash kubectl delete role mas-application-admin -n <namespace> kubectl delete rolebinding mas-application-admin-binding -n <namespace>

  2. Or remove the namespace sub-directory from the overlay and re-apply: bash rm -rf rbac/kustomize/overlays/<service-account-name>/<namespace> # Remove the entry from the parent kustomization.yaml resources list kubectl apply -k rbac/kustomize/overlays/<service-account-name>

References¤