The three connection methods · ZopDev University

Outcome

By the end of this lesson, you will be able to choose between the three connection methods, identify which one writes to the customer’s cluster, and explain why provisioning is an explicit per-cluster action with no bulk option.


Tier	Operator
JTBD	”Pick the connection method my security team will actually approve.”
Personas	Platform Engineer · Security/Compliance · SRE
Prerequisites	M1.7.L1
Time	9 minutes
Bloom verb	Choose (Evaluate), Identify (Remember), Explain (Understand)

1. Concept

There are three ways in, and ZopNight offers them one cluster at a time, based on what that cluster and your credential actually allow.

Two clusters in the same organisation can offer you different lists. That is not a bug, and the rest of this lesson is why.

1. AUTOMATIC
   ZopNight creates an htpasswd identity through OCM and
   grants it cluster-admins.
   Needs:  OCM Organization Administrator role
   THE ONLY PATH THAT WRITES TO YOUR CLUSTER.

2. CLUSTER LOGIN
   You create the htpasswd identity and bind a read role.
   We exchange your username and password for a
   short-lived token.
   ZopNight provisions NOTHING.

3. SERVICE ACCOUNT
   You create a Kubernetes ServiceAccount and hand over
   its token.
   Never touches OAuth at all.

Choosing, in the order that usually decides it

DOES THE CLUSTER USE EXTERNAL AUTHENTICATION?
  YES -> SERVICE ACCOUNT is your only option.
         Methods 1 and 2 both go through OpenShift's
         OAuth server, and a cluster running external
         authentication does not have one to use.

  NO  -> continue

WILL YOUR SECURITY TEAM ACCEPT US WRITING AN IDENTITY
PROVIDER, A USER AND A GROUP MEMBERSHIP TO THE CLUSTER?
  NO  -> CLUSTER LOGIN or SERVICE ACCOUNT
  YES -> AUTOMATIC is the least work

DO YOU HAVE OCM ORGANIZATION ADMINISTRATOR?
  NO  -> AUTOMATIC is not offered to you anyway

In practice most enterprises land on service account: it is the only method that touches neither OAuth nor the cluster’s identity configuration, and it is the easiest to describe in a change request.

What “automatic” actually writes

Be precise about this, because it is the question a security reviewer will ask:

AUTOMATIC creates, through OCM:
  - an htpasswd identity provider (if not present)
  - a user in it
  - a group membership granting cluster-admins

cluster-admins is a broad grant. It is what makes the
method work without further configuration, and it is
also why the other two methods exist.

Cluster login, by contrast, binds a read role that you choose, so the grant is as narrow as you make it.

Why provisioning is explicit

IT IS A PER-CLUSTER ACTION WITH A MATCHING DISCONNECT,
and deliberately not a side effect of opening a page.

WHAT IT REPLACED
  Reading access used to write an identity provider, a
  user and a group membership to the customer's cluster
  the first time anyone opened the workload view, with
  nobody having agreed to it.

That history is worth knowing because it explains the shape of the current design. The connect card is not friction for its own sake; it is consent, at the point where something gets written.

Why there is no bulk connect

Clusters are connected one at a time, from "Manage
clusters" on the account card or from the cluster's own
page.

THE REASON: the three methods collect three DIFFERENT
KINDS OF CREDENTIAL. One bulk action cannot ask for an
OCM admin grant, a username and password, and a
ServiceAccount token simultaneously, and offering only
the automatic method in bulk would push everyone toward
the one path that writes to their clusters.

Disconnect

Every method has a matching disconnect that cleanly removes what it added. For the automatic method that means removing the identity and group membership it created; for the other two there is nothing on the cluster to remove, because nothing was provisioned.

That asymmetry is a good argument for the service-account method in an estate where clusters get connected and disconnected regularly.

2. Demo

Three clusters, three different methods, in one organisation:

CLUSTER A: prod-rosa-01
  External authentication: YES (enterprise IdP)
  Methods offered: SERVICE ACCOUNT only

  The two OAuth-based methods are not offered, because
  there is no OpenShift OAuth server in play on this
  cluster. Not a permissions problem; the mechanism
  those methods use is simply absent.

  Set up: platform team created a ServiceAccount with a
  read-only ClusterRole binding, handed over the token.
  Elapsed: about 10 minutes, one PR against their
  cluster-config repo.

CLUSTER B: staging-rosa-01
  External authentication: no
  OCM role: Organization Administrator held by the
            connecting user
  Methods offered: ALL THREE

  Security review asked one question: "does anything get
  written to the cluster?"
    automatic     -> yes: an IdP, a user, a group
                     membership granting cluster-admins
    cluster login -> no
    service acct  -> no

  They chose CLUSTER LOGIN, created the htpasswd identity
  themselves, and bound a read role scoped narrower than
  cluster-admins.

CLUSTER C: dev-rosa-01
  Same profile as B. Chose AUTOMATIC.
  Rationale: a dev cluster rebuilt every few weeks, where
  10 minutes of setup per rebuild was not worth it and
  cluster-admins on a disposable cluster was acceptable.

  Disconnect on rebuild cleanly removes the identity and
  group membership, so no residue accumulates.

WHAT THE ORGANISATION LEARNED
  The method is a per-cluster decision, not an
  organisational standard. The same team correctly used
  all three, because the clusters differ in what they
  support and in what the change is worth.

3. Hands-on (6 min)

1. For one cluster, open the connect card. Which methods
   are offered?
   [ ] automatic  [ ] cluster login  [ ] service account
   If service account is the ONLY one, what does that
   tell you about the cluster?
   ______________________________________________

2. Answer the security question in advance:
   Which method writes to the cluster?  ______________
   What exactly does it write?
   ______________________________________________

3. Check your OCM role. Do you hold Organization
   Administrator?                             Y / N
   If N, which method is unavailable to you? ________

4. Pick a method and note the narrowest role you could
   bind (cluster login and service account let you
   choose; automatic does not):
   ______________________________________________

5. Confirm the disconnect story before connecting:
   what would be left on the cluster afterwards?
   ______________________________________________

Why this part is console only. Connecting a ROSA cluster is done in the console, through OpenShift Cluster Manager or the cluster credentials. There is no way to do it from an assistant, by design: the connection carries cluster credentials.

Once it is connected, an assistant can read the cluster for you: which clusters exist, what workloads run on them, and what they cost. The workload view in L3 answers in one question.

Tools that read it afterwards: list_cloud_clusters (read, Ship), get_kubernetes_cluster_workloads (read, Cost), get_kubernetes_cluster_costs (read, Cost). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

A ROSA cluster runs external authentication. Which connection methods are available?

A. All three
B. Service account only
C. Automatic and cluster login
D. None; external authentication is unsupported

Show answer

Correct: B. Both the automatic and cluster-login methods go through OpenShift’s OAuth server, and a cluster running external authentication does not have one in play, so the service-account method (which never touches OAuth) is the only one that works. This is why the methods are offered per cluster rather than as an organisational setting: what a cluster supports is a property of that cluster, and the same team may legitimately use all three across their estate.

Q2

Which method writes to the customer’s cluster, and what does it write?

A. All three write a service account
B. Automatic only
C. Cluster login, because it creates the htpasswd identity
D. Service account, because it creates a ServiceAccount

Show answer

Correct: B. It creates an htpasswd identity provider, a user in it, and a group membership granting cluster-admins, all through OCM. Cluster login and service account provision nothing: you create the identity and ZopNight is given a credential for it. In C and D the customer creates the identity as a prerequisite, which is the distinction that matters to a security reviewer. The cluster-admins grant is also why the other two methods exist: it is broad, and cluster login lets you bind something narrower.

Q3

Why is there no bulk connect action across clusters?

A. Rate limits on the OCM API
B. Each cluster requires its own separate OCM organisation, so there is never more than one cluster to connect at a time from any one single credential set
C. The three methods collect three different kinds of credential, and one action cannot ask for an OCM admin grant, a username and password, and a ServiceAccount token at once
D. Bulk actions are not supported for any provider

Show answer

Correct: C. Offering only the automatic method in bulk would push everyone toward the single path that writes to their clusters. The same reasoning is why setting up access is now something you ask for. It used to happen by itself. Opening the workload view wrote an identity provider, a user and a group membership to the cluster, the first time anybody looked, without anyone having agreed to it.

5. Apply

Decide your method per cluster rather than per organisation, and answer the “does anything get written to the cluster” question before the security review asks it. For estates where clusters are rebuilt often, the service-account method leaves nothing to clean up.

Glossary terms touched

htpasswd identity · cluster-admins · External authentication · ServiceAccount token

Outcome

1. Concept

Choosing, in the order that usually decides it

What “automatic” actually writes

Why provisioning is explicit

Why there is no bulk connect

Disconnect

2. Demo

3. Hands-on (6 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.