Infrastructure

Create a read-only service account, rather than pointing at a cluster-admin context:

kubectl create serviceaccount triagic -n default
kubectl create clusterrolebinding triagic-view \
  --clusterrole=view --serviceaccount=default:triagic

The view ClusterRole is Kubernetes' own read-only aggregate.

Choose how to reach the cluster. Authentication method decides which other fields appear.

Paste a kubeconfig is the answer for a shared data source. Produce a self-contained file and paste the whole thing:

kubectl config view --raw --minify --flatten

--raw keeps the credentials (a plain config view redacts them), --minify drops every context except the current one, and --flatten inlines certificates that would otherwise be paths to files no other machine has. Switch context first if the one you want is not current.

Kubeconfig file on this machine is the usual answer for your own laptop: build a kubeconfig from the service account above and give its path.

API server and service-account token suits a machine with no kubeconfig on it. Mint a token for the account and read the cluster's CA out of any existing kubeconfig:

kubectl create token triagic --duration=8760h
kubectl config view --raw --minify \
  -o jsonpath='{.clusters[0].cluster.certificate-authority-data}'

The second command prints the value for Cluster CA certificate. It's already base64-encoded, and it goes in the field as-is. There is no way to give a CA file path here, only that string.

In-cluster service account is for a Triagic running as a pod in the cluster it reads. It takes no fields: the server finds the pod's own mounted service-account token.

Fill the form.

Verify. Health check lists API resources.

Decide which engine to read. Blank means the Docker engine on the machine running Triagic, which is right for a developer laptop or a Triagic that already lives on the host you care about.

For a remote server, ssh://you@host.example.com is the method to reach for. It uses the OpenSSH configuration of the machine running Triagic, so it works exactly when ssh you@host.example.com works there, and it needs nothing opened on the server. Give that SSH user read access to the socket (on Linux: membership of the docker group).

Only for a tcp:// engine: collect the TLS material. A tcp:// daemon with no TLS is an unauthenticated root shell on that host: treat one as a finding, not as a connection option. With TLS, copy ca.pem, cert.pem and key.pem into one directory on the machine running Triagic; those three names are fixed, because the client appends them to the directory itself.

Fill the form.

Verify. Health check lists containers, a real call to the daemon, so a socket that isn't there fails the save rather than leaving a row that starts and answers nothing.

Create an API token. HCP Terraform → Account settings → Tokens, or a team token scoped to read access, which is the least-privilege option. User, team and organization tokens all work.

Get the CA bundle, for Terraform Enterprise behind a private CA. HCP Terraform uses a public CA and needs nothing here. A self-hosted instance usually presents a certificate from your own internal CA, which the container has no reason to trust. Ask whoever runs it for that CA's PEM bundle and save it on the machine running Triagic. You give the host path and it is mounted into the container for you.

Fill the form.

Verify. Health check is get_token_permissions, not whoami: no such tool exists in the pinned image. It still fails precisely when the token is wrong. Without it the server would still start (the registry side needs no token at all) and every workspace tool would fail later instead.

Create a Kafka API key. Confluent Cloud → your cluster → API keys → Add key. Keys are per-cluster; a key from a sibling cluster fails with an authentication error.

Create it for a service account, not for your own user account: a key made under "My account" carries everything you can do, and dies with your membership. Give the service account read-only access: the DeveloperRead role (or ACLs granting READ/DESCRIBE) on the topics and consumer groups you want visible. The read-tool allowlist on this side keeps the agent read-only; the service account's grants make that hold at the cluster too, and decide which topics are readable at all.

Collect the cluster's REST endpoint and ID from the cluster overview, if you want the topic and consumer-group tools (you do, consumer lag is the point).

Optionally add the control-plane and Schema Registry keys. The Confluent Cloud API key is a separate, account-level key that lists environments and clusters. The Schema Registry endpoint has its own key pair again.

Only for a self-hosted cluster: write a Kafka client config file.

Confluent Cloud needs nothing here. The server talks SASL/PLAIN over TLS and has no setting for anything else (not SCRAM, not mTLS, not a private CA), so a self-hosted cluster wanting one of those needs a librdkafka properties file, which is the one override that can supply them.

Write it on the machine running Triagic and give the absolute path. Be aware of what you are trading: that file overrides every field above, and it holds credentials on disk in plain text rather than encrypted alongside the rest of this form. Restrict it to the user Triagic runs as.

security.protocol=SASL_SSL
sasl.mechanisms=SCRAM-SHA-512
sasl.username=triagic
sasl.password=…
ssl.ca.location=/etc/ssl/certs/kafka-ca.pem

Fill the form.

Verify. Health check lists topics, a real Kafka read, deliberately not one of the server's credential-free diagnostics, which would answer happily for a broken config.