OCM

Clarity Transform discovers a whole Kubernetes fleet from a single Open Cluster Management hub, tunnelling the per-cluster API calls through the hub's cluster gateway, so no per-cluster credential or network path is needed.

Where to find it

Go to Discover → Integrations, then select the OCM card. The card's category label is Containers. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

In a container platform the application boundary is largely declared rather than inferred, because the platform already knows which pods constitute a service. That is a materially better starting position than a network-derived guess.

Clarity takes that declared structure as evidence, then connects it outwards to the traffic those workloads exchange with the rest of the estate, which is usually where the migration risk sits. A cluster that is self-contained is easy. A cluster whose pods call three databases on physical hardware is the problem, and that boundary is exactly what the platform itself cannot tell you.

The hub model changes the access conversation rather than the discovery.

What we collect

The hub's ManagedClusters, and then, through the hub's cluster gateway, the same clusters, nodes, namespaces and workloads the OpenShift integration collects directly.

• The fleet: every cluster registered with the hub
• Per cluster, through the cluster gateway: clusters, nodes, namespaces and workloads

Advanced Cluster Management presents the same API

Red Hat Advanced Cluster Management (ACM) is the downstream product of the same upstream project, so an ACM hub is discovered by this integration without anything different being configured.

What it adds

A fleet-level view that per-cluster discovery cannot produce: which clusters exist, and which of them nobody remembered to mention. On a large container estate the unknown clusters are often the finding.

Clusters not registered with the hub still need their own endpoint, and the two models coexist without conflict. So a partially adopted hub is a normal starting position rather than a problem to solve first.

What is deliberately not inferred

TLS verification is disabled on the cluster API connection

Every authentication mode passes --insecure-skip-tls-verify=true, so a self-signed or internally issued API certificate connects without its CA being trusted on the Clarity host. The connection is encrypted; the server certificate is not validated.

• No secret values.
• No container images or filesystems, and no application data.
• No exec, attach or port-forward. The role grants none of them.
• Nothing is written. Every verb granted is get or list.
• Co-location in a namespace is not a dependency. A namespace is an organisational boundary; two workloads sharing one are not related by that fact alone.

What we require

The requirement below is read from rb-pautol-ocm-connect-hub.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Account required: a ServiceAccount on the OCM hub with read access to ManagedCluster resources under cluster.open-cluster-management.io, plus the same read-only ClusterRole the OpenShift and NKP integrations need on each managed cluster it enumerates.

The hub credential enumerates the fleet; discovering the contents of each managed cluster still needs access to that cluster. A hub token alone lists the clusters and reads nothing inside them, which presents as a fleet of empty clusters rather than as a permission error.

Three authentication modes are supported, not just tokens. The mode is chosen by Get-ContainerAccessMode in rb-pautol-openshift-common.ps1, in this order:

• Kubeconfig, when the endpoint's discovery method is kubeconfig (or config / kube-config), or the endpoint value is a path to an existing file, or the endpoint is blank and KUBECONFIG is set in the environment.
• Bearer token, when the discovery method is token (or bearer / bearer-token), or the credential username is literally token, bearer or oauth. The password holds the token.
• Username and password, which is the default for any ordinary username. It runs oc login into a temporary kubeconfig and removes it afterwards.

A ServiceAccount bearer token is what we ask for and what the role guidance above assumes, because it is scoped, revocable on its own and carries no interactive session. The other two modes work and are worth knowing about when a customer cannot issue a token.

Username and password needs oc specifically. kubectl has no interactive login, so where only kubectl is present on the Clarity host this mode fails with a clear error rather than falling back. Token and kubeconfig work with either CLI.

TLS verification is disabled on the cluster API connection. All three modes pass --insecure-skip-tls-verify=true, so a self-signed or internally issued API certificate connects without the CA being trusted on the Clarity host. State this rather than let a customer's security review discover it: the connection is encrypted, but the server certificate is not validated.

Connectivity: HTTPS to the hub API server, conventionally TCP 6443.

Every verb is get or list. Discovery never writes to the hub or to a managed cluster.

Verification before handover

1. Confirm the hub credential authenticates, in the mode you intend. A username of token, bearer or oauth selects bearer-token auth with the token in the password field. Any other username falls through to oc login with that username and password, which also works.
2. Confirm the fleet lists. Read managedclusters. An empty fleet rather than an error is the signature of missing permission here, so an empty result should be treated as a permission question rather than as an empty hub.
3. Confirm the gateway proxy works for one cluster. Read something trivial on a managed cluster through the hub. This is the leg that needs clustergateways and its proxy subresource, and it is the one most often missed, because listing the fleet succeeds without it.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The hub API server address, conventionally on TCP 6443
Credential	Recommended: username token with the ServiceAccount bearer token as the password. An ordinary username and password also works, and uses oc login
Job Schedule	A five-field cron expression, for example 0 0 * * * (daily)
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Delete the bindings, roles and ServiceAccount on the hub, and the read-only role on each managed cluster. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
An empty fleet rather than an error	The hub account lacks get/list on managedclusters and clustergateways, or on the clustergateways/proxy subresource. The hub returns an empty fleet rather than a permission error, so this is the expected symptom.
The fleet lists but every cluster is empty	The gateway proxy permission is missing, or the per-cluster read-only role has not been created. Listing the fleet succeeds without either.
A cluster is missing from the fleet	It is not registered with the hub. It needs its own OpenShift endpoint; the two models coexist.
Authentication fails with a valid token	The credential username is not token.