Outcome
By the end of this lesson, you will be able to explain why a ROSA cluster connects against an OCM organisation rather than its AWS account, explain why an OCM credential cannot read the cluster, and interpret a 424 on the workload view.
| Tier | Operator |
| JTBD | ”Understand why my ROSA cluster appears but shows no workloads.” |
| Personas | Platform Engineer · SRE · Security/Compliance |
| Prerequisites | T1.M1.1 (connecting a cloud account) |
| Time | 9 minutes |
| Bloom verb | Explain (Understand), Interpret (Analyze) |
1. Concept
A ROSA cluster runs on AWS, and it does not connect through your AWS account.
IT CONNECTS AGAINST AN OPENSHIFT CLUSTER MANAGERORGANISATION, as its own cloud account.
provider = `openshift` on every discovered resource.
So filtering the resource list by `aws` deliberately doesNOT return your ROSA clusters. They are not AWS resourcesin ZopNight's model, even though the instances underneaththem are.That surprises people, and the reason is the whole lesson.
An OCM credential is not a Kubernetes credential
On EKS, GKE and AKS, the identity you connected the cloud account with can already log in to the cluster itself. Connect the AWS account and you can read the cluster. Nothing else is needed.
ROSA breaks that assumption.
Two separate services are involved, and each decides for itself who it trusts.
TWO SEPARATE SERVICES, TWO SEPARATE TRUST DOMAINS
OCM (api.openshift.com) Red Hat's cluster manager. Knows your clusters exist, their machine pools, their configuration. Authenticated with an OCM service account.
THE CLUSTER'S OWN KUBERNETES API Knows the workloads. Authenticated with a Kubernetes credential.
An OCM credential proves who you are to Red Hat's manager.The cluster has never heard of it. It cannot read thecluster, and no amount of OCM permission will change that.So a discovered ROSA cluster is listed but unreadable until its cluster access is established explicitly, as a separate step.
What that looks like in the product
THE WORKLOAD VIEW REPORTS 424, and the UI shows aconnect card.
424 is the right status here: it means the requestdepends on something that has not been done yet. It isnot an authorization failure and it is not an outage.The dependency is "this cluster's access has not beenprovisioned".Reading the 424 correctly saves a support ticket. The cluster is fine, the credential is fine, and the missing thing is a deliberate action nobody has taken yet.
OpenShift adds its own authentication layer
OPENSHIFT'S OAUTH SERVER authentication (who are you)STOCK KUBERNETES RBAC authorization (what may you do)
THEY ARE INDEPENDENT.
An identity that belongs to no group authenticatesperfectly well and can do nothing at all.This matters when you are debugging a connection that “worked” and returns nothing: authenticating successfully is not evidence of being authorized, and on OpenShift those two steps are separated more visibly than on stock Kubernetes.
Nothing here is schedulable
Worth establishing immediately so nobody plans around it:
NO ROSA RESOURCE IS SCHEDULABLE OR SCALABLE in thestart/stop sense.
WHY: worker nodes are RED HAT-MANAGED. Stopping orresizing them directly falls outside Red Hat's serviceboundary, so the platform does not offer it.
Resizing a pool through OCM (L4) is a CONFIGURATIONchange, not scheduling.So ROSA in ZopNight is a visibility and configuration integration. If your reason for connecting it is off-hours shutdown, that is not available and it is not a gap that will close: it is a boundary of the managed service.
Why the connection is explicit, and what it fixed
Provisioning cluster access is a per-cluster action with a matching disconnect, and it is deliberately not a side effect of opening a page.
WHAT USED TO HAPPEN Reading access wrote an identity provider, a user and a group membership to the customer's cluster the first time anyone looked at it. Nobody had agreed to that.
WHAT HAPPENS NOW You click connect, per cluster, choosing a method. You can disconnect, and it cleanly removes what it added.There is also no bulk action, for a reason that is easy to miss: the three connection methods collect three different kinds of credential, and one bulk action cannot ask for all three at once.
2. Demo
A first ROSA connection, and the support ticket it nearly generated:
DAY 1 Connected an OCM service account. Cloud Accounts now shows: "OCM: acme-production"
Resources, filtered provider=openshift: openshift-cluster 3 openshift-machinepool 7
The team then filtered provider=aws to find them again and got nothing. First confusion: ROSA clusters are `openshift`, not `aws`, even though the EC2 instances under them are AWS instances Red Hat manages.
DAY 1, TEN MINUTES LATER Clicked into prod-rosa-01 -> Workloads tab. Response: 424. A connect card.
THE TICKET THEY ALMOST FILED "Discovery is broken, we can see the cluster but no workloads. Permissions issue?"
THE ACTUAL SITUATION Nothing is broken. The OCM credential told us the cluster exists. Reading its workloads needs a KUBERNETES credential, which is a different trust domain, and nobody had provisioned one yet.
DAY 1, AFTER READING THE CONNECT CARD Chose the service-account method on prod-rosa-01 (their clusters run external authentication, which rules out the two OAuth-based methods; see L2).
Workloads tab now populated: Deployments, StatefulSets, the usual set, plus Routes, DeploymentConfigs, BuildConfigs, ImageStreams and Projects.
DAY 2 Asked whether the three clusters could be put on an off-hours schedule. Answer: no, and never. Worker nodes are Red Hat-managed and stopping them is outside the service boundary.
They used the pool-resize configuration path instead (L4) to drop the dev cluster's pool from 6 nodes to 3 outside business hours, as a manual change.3. Hands-on (6 min)
1. Filter Resources by provider=openshift. What appears? openshift-cluster ______ openshift-machinepool ______
2. Now filter by provider=aws. Do your ROSA clusters appear? Y / N Explain why in one line: ______________________________________________
3. Open a cluster's Workloads tab BEFORE provisioning access. What status? ______ Is that an authorization failure? Y / N
4. Write, in your own words, the difference between the OCM credential you connected and the credential the workload view needs: ______________________________________________
5. If your reason for connecting ROSA was off-hours shutdown, note the alternative now: ______________________________________________4. Knowledge check
Q1
A ROSA cluster runs on AWS. In ZopNight it is connected:
A. As its own cloud account against an OpenShift Cluster Manager organisation, with provider = openshift on every discovered resource
B. Through the AWS account that hosts it, in exactly the same way that any EKS cluster would normally be connected to it
C. Through the Red Hat marketplace integration
D. As a Kubernetes cluster under the EKS provider
Show answer
Correct: A. Filtering the resource list by aws deliberately does not return them. The instances underneath the cluster are AWS instances that Red Hat manages, which is what makes the provider split confusing. In ZopNight’s model the cluster belongs to the OCM organisation that manages it.
Q2
The workload view on a newly discovered ROSA cluster returns 424. This means:
A. The OCM credential lacks the permission that is needed to read any of the cluster workloads
B. The request depends on something not yet done: this cluster’s Kubernetes access has not been provisioned
C. The cluster is unreachable
D. Discovery has not completed
Show answer
Correct: B. An OCM credential authenticates to a different service in a different trust domain and cannot read the cluster API, so establishing cluster access is a separate, explicit per-cluster step. Reading the 424 correctly saves a support ticket: the cluster is fine and the credential is fine. On EKS, GKE and AKS the account’s own principal can already reach the cluster API, which is why this step has no equivalent there.
Q3
Can a ROSA cluster or machine pool be attached to a ZopNight schedule?
A. No, and this will not change
B. Yes, like an EKS node group
C. Only machine pools, not clusters
D. Only with the automatic connection method
Show answer
Correct: A. Worker nodes are Red Hat-managed, so stopping or resizing them directly falls outside Red Hat’s service boundary. Resizing a pool through OCM is a configuration change rather than scheduling. This is a boundary of the managed service rather than a missing feature. If off-hours shutdown was the reason for connecting, the honest answer is that ROSA here is a visibility and configuration integration.
5. Apply
Connect your OCM organisation, then expect to provision cluster access separately for each cluster you actually need workload visibility on. Read the 424 as “not yet provisioned” rather than as a failure.
Set expectations early with anyone who asked for ROSA scheduling: it is not available, and the configuration path in L4 is the nearest thing.
Related lessons
- L2: The three connection methods (next)
- L3: Discovery and the workload view
- T1.M1.1.L1: Vault credentials
- T2.M2.6.L1: Why K8s is hard to cost-optimize
Glossary terms touched
OCM · ROSA · Trust domain · Machine pool