Multi-tenant platform for six departments with showback
A university with six departments (research, finance, HR, student, alumni, and IT) wants one IBM Cloud Pak for Data platform for 400 users. Research needs GPU for deep learning; finance has SOX separation requirements; HR handles sensitive employee data. The OpenShift cluster has 12 worker nodes, 4 with GPUs. Budget requires a single cluster, and the CIO wants self-service project creation without giving users cluster-admin. Current authentication is LDAP; there is no SAML identity provider. Departments demand monthly showback by CPU, memory, GPU, and storage. The platform team wants to avoid running six CP4D instances. Auditors ask whether finance can share the platform with research.
1. Design the tenancy model using CP4D projects, OpenShift namespaces, RBAC, and quotas. What is the real boundary?
Read the worked answer
Use one CP4D instance with OpenShift projects mapped to CP4D projects, LDAP groups mapped to platform and project roles, and self-service project creation constrained to approved templates. Apply ResourceQuota and LimitRange per namespace so one department cannot consume the cluster. Put GPU workloads on the four GPU nodes with taints and tolerations, and create a separate GPU machine pool so research jobs do not starve finance batch jobs. Use NetworkPolicies between departmental namespaces where services allow it. The real boundary is the cluster and the CP4D instance, not the CP4D project: projects isolate collaboration assets and can restrict membership, but platform administrators and some cluster-scoped services still span departments. For finance, use a separate catalog, restricted project membership, and audited admin access; if auditors require separate administrative domains, a single instance may not satisfy them.
2. How do you implement showback by department without native billing?
Read the worked answer
Build showback from OpenShift monitoring and CP4D usage data. Collect namespace-level CPU and memory requests and usage, PVC capacity, GPU allocation time, and pod hours through Prometheus or the platform monitoring stack. Map namespaces to departments through labels and a cost table. Add CP4D service usage where available, such as notebook runtime hours or WML deployment hours, and allocate shared platform overhead by an agreed formula. Publish a monthly report with both requested and consumed resources so departments see the effect of over-requesting. Do not present this as a bill unless finance accepts the rates. Validate the report against actual node capacity and storage invoices; showback that does not reconcile to real cost will lose credibility.
3. Finance requires SOX separation. Is a single CP4D instance acceptable, and what compensating controls would you require?
Read the worked answer
A single instance can be acceptable only if the auditors accept logical separation with strong compensating controls. Require a dedicated finance project and catalog, restricted membership, separate encryption keys or storage class where supported, network policies that block other departments, audited platform-admin access, and change approval for finance namespaces. Finance data should not be co-mingled in shared catalogs, and finance users should not be catalog stewards for other departments. If auditors require separate admin domains, separate upgrade windows, or evidence that a platform admin cannot read finance data, then a single CP4D instance is not sufficient; use a separate cluster for finance. The decision is a risk acceptance, not a technical preference. Document the exact control gap and get auditor sign-off before go-live.