How the ClusterTriage script handles credentials

A ClusterTriage measurement runs a script in your environment. The script reads data and collects it in one file that you upload to the portal. This page says what that script does with credentials, and what it does not do.

We checked this in the code that is actually shipped. Where a check enforces something, we say so. Where nothing enforces it, we say that too.

The script signs in as the administrator who starts it

The script connects to the cluster nodes under the account of the person who runs it. It never passes credentials on to another machine. No password goes from hand to hand. We checked this over every connection the script makes: none of them passes a credential along.

We do not use CredSSP. That is the technique where a password is handed to the machine you connect to, so it can sign in somewhere else. A measurement that only reads does not need it. Our build check refuses every line of code that uses CredSSP, so it cannot slip in unnoticed.

Traffic between the machines stays encrypted. We never turn that off, and the build check refuses that as well.

Passwords never enter the script as plain text

Where the script does need a credential, for example for a storage array or a BMC, it takes it as a secure object. PowerShell refuses a plain text value there. That is not an agreement but a limit the language itself sets. Where the script is not given a credential, it asks for one itself.

One exception, which we would rather name than leave out. The instruction card for a storage array describes a way of working where the administrator first pastes the API token into an ordinary variable, which is then converted and deleted straight away. That is a deliberate choice: on some servers a secure input field cut a pasted token down to one character during a real measurement, and the measurement then failed although the token had been typed.

In addition, two brands of storage array sign in with user name and password inside the request itself. That value exists in memory for a few lines and is then cleared. That is how those APIs work, not a choice of ours.

No passwords on the command line

The commands we prescribe pass a variable, not the value itself. If a transcript runs on the server, it shows the variable's name and not the token. The build check refuses every prescribed command that spells out a password.

No passwords in output or error messages

No place in the script prints a credential. When a connection fails, the error shows the status code and not what was sent. The build check refuses every line that writes a credential to the output. The two storage array sign-ins named above are marked explicitly with a reason; a third cannot be added unnoticed.

We read the output back before it is handed over

Before the result file is made, the script reads its own output and looks for values that resemble a credential. If it finds one, the file is not made. The collected data stays on the server; only the handover stops.

We refuse rather than warn, for a practical reason: this happens at the moment someone finishes a job, and that is exactly when a warning gets clicked away.

What this check is and is not. It is a sieve. It recognises what looks like a credential: a field named like password or api_token, an Authorization header, a connection string with a password in it, or a private key. A value that does not look like that passes unnoticed. The script says this in its own output too, also when nothing is found. We do not want "we scan" to be read as a guarantee.

The package is ours, and you can check that

The checksums of each script version are published on our website at https://clustertriage.com/checksums/. You can compare the files you downloaded with that list before you run anything.

What you can check yourself

We cannot promise what ends up in your own logs. Whether Windows records what a script does is your policy, not something we can enforce.

What you can do: run the script once on a server where that recording is on, and look in the event logs afterwards. Windows has two forms. The first records the text of the code that ran; it shows the variable's name, not the value. The second also records parameter values, and that is where a password would show if there were one. The sign-in to a storage array is the sharpest place to look.

In short