Private OpenShift Platform for Canadian Claims Intake
HealthClaims Canada is implementing a claims-intake platform on Red Hat OpenShift on IBM Cloud in the Toronto region. The platform has 42 microservices owned by three product teams, and all PHI must remain in Canada. Peak intake is four times baseline on Monday mornings. The cluster must pull images from a private registry, and security policy forbids pods from reaching the public internet directly. The mainframe adjudication system is on-premises and reachable only through an existing IBM Cloud Direct Link. Developers need self-service deployments, but production changes require segregation of duties and an audit trail. The current proposal gives every team a dedicated cluster, a shared default namespace in production, and a single service ID with cluster-admin for CI/CD. Security has flagged this proposal, and the platform must be production-ready in 10 weeks. The team also wants to avoid operating its own container registry if a managed option is available.
1. Evaluate the proposal to give each team a dedicated cluster. Recommend a target cluster and namespace model, and explain the trade-offs for isolation, cost, and a 10-week delivery window.
Read the worked answer
Use a shared OpenShift cluster with projects, not dedicated clusters per team. Three teams and 42 services do not justify three control planes, three upgrade cycles, and three observability stacks; with 10 weeks, operational overhead is the main risk. Use one production cluster per region, separate clusters for dev/test, and one project per team plus one per environment within the cluster. Enforce resource quotas, LimitRanges, NetworkPolicies, and RBAC at project scope. Reserve dedicated clusters only for a team with a regulatory or kernel-level isolation requirement, which is not stated here. Never use the default namespace for production; it defeats quota and policy scoping. The shared-cluster design also makes it easier to apply consistent image and egress policy. If noisy-neighbor risk appears later, isolate with node pools and taints rather than new clusters. Document the upgrade window and a cluster-level blast-radius plan, because a shared control plane concentrates risk even as it reduces cost.
2. Design the private image supply chain and pod egress path. How do you enforce no public internet access while still allowing the mainframe dependency and managed registry?
Read the worked answer
Put images in IBM Cloud Container Registry in the Toronto region and pull through private endpoints. Use image pull secrets bound to a service ID, and run scanning in the pipeline. Deny egress by default with NetworkPolicies and do not attach a public gateway to worker subnets. Allow only the private registry endpoint, DNS, and the on-premises mainframe route over Direct Link. For any approved external dependency, route through a firewall or network virtual appliance in a dedicated egress subnet, log the flows, and require an exception. Terminate the Direct Link path in a transit VPC connected by Transit Gateway, not in each application VPC. That gives one inspection point and avoids 42 services each building its own route. Scan and sign images before deployment; block latest tags and untrusted registries with an admission policy. The key judgment is that private connectivity is not just a firewall rule: it is a default-deny path with a small, auditable set of allowed destinations.
3. How would you implement segregation of duties and audit evidence for production deployments without slowing the three teams to a halt?
Read the worked answer
Replace the shared cluster-admin service ID with pipeline-scoped identities. Each team gets a CI service ID that can push to its own registry namespace and update only its project. Production deployment uses a separate service ID with a deployment role and an approval gate. Humans get RBAC through groups, with cluster-admin limited to a break-glass group under MFA and just-in-time elevation. Store secrets in Secrets Manager or OpenShift secrets backed by an external store; never in CI variables. Enable OpenShift audit logging and forward cluster, VPC flow, and Activity Tracker events to a central COS bucket with retention. The audit trail should answer who changed what image, who approved it, and which pod ran it. Segregation of duties is not two people clicking; it is different identities, different permissions, and evidence that the production identity could not push its own image. Keep the approval gate to one required approver with an emergency path to avoid becoming the bottleneck.