Skip to main content

Credential brokering

Overview​

Credential brokering is the central idea behind NebCLI. NebCLI never creates or stores a long-lived secret. Instead, when a task needs access to the cloud, a cluster, GitHub, or the chart registry, NebCLI asks the platform for a short-lived credential, writes it exactly where the matching standard tool already looks, and then steps aside so you use that tool directly. When the credential expires, NebCLI fetches a fresh one. Understanding this one pattern explains how every access-related command in NebCLI behaves.

Why no long-lived secrets​

A long-lived secret is a password-like value that does not expire quickly. When one of those sits on many laptops and CI runners, it becomes the single thing most likely to leak, and it stays dangerous long after it leaks. NebCLI is built so that this risk does not exist on your machine. Only one component in the platform is allowed to create credentials at all, and every credential it creates is short-lived. NebCLI itself holds none.

The broker pattern​

Every kind of access NebCLI manages follows the same five steps:

  1. NebCLI asks the platform for a credential.
  2. The platform creates a short-lived credential and returns it.
  3. NebCLI writes that credential to the exact location the relevant standard tool reads from.
  4. The standard tool (aws, kubectl, helm, git) runs on its own, using that credential.
  5. When the credential expires, NebCLI fetches a fresh one and replaces only the expired one.

The important detail is step 4: once NebCLI has prepared a credential, it gets out of the way. It does not sit in the middle of every later call. You run the standard tool exactly as you normally would, and it talks to its target system directly.

This is why, across the tool, the recovery from an expired credential is always the same shape: a standard tool rejects the access, you run the matching nebcli ... refresh, and you retry the original command.

Proving identity is not the same as being allowed​

Before NebCLI brokers anything, it proves who is asking. A person proves identity with a session created at sign-in; automation running inside the platform proves identity with a key it is given. NebCLI prefers the agent key when both are present.

Proving identity is separate from being allowed. After NebCLI proves an identity, the platform still decides whether that identity may perform the specific action, and at sign-in NebCLI sets up only the access you are permitted to have. You cannot broker access you are not entitled to.

Forward-only by design​

NebCLI moves forward only. When a capability changes, the old way is not kept alongside the new one: there are no legacy options, no compatibility modes, and no fallback paths. The behavior you see today is the single current behavior, with no hidden alternate path to reason about.

Supply-chain verification​

The same no-trust-without-proof posture extends to the program itself. Every NebCLI release is signed and recorded in a public transparency log, and the signature is verified before the binary is installed. The check cannot be turned off for a shipped binary. That is why the installation steps run cosign verify-blob against the public key from the nebinfra/trust repository before installing: it confirms the copy you are about to run was produced by the platform and has not been altered.

Next steps​

  • Installation: install and verify NebCLI.
  • Authentication: sign in and manage your session.
  • Commands: the cloud, cluster, GitHub, and registry access commands.
  • Examples: the broker pattern applied to real tasks.