Credential brokering
Overview
Principal and access credential brokering is the central idea behind NebCLI. NebCLI never creates or stores a long-lived principal or access 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 pattern explains how every currently delivered access-related command in NebCLI behaves.
Why no long-lived secrets
A long-lived principal or access 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's delivered principal and access paths avoid that risk on your machine. Only the platform credential authority may mint those credentials, every credential it mints is short-lived, and NebCLI keeps no long-lived copy.
The broker pattern
Every delivered principal and access credential that NebCLI manages follows the same five steps:
- NebCLI asks the platform for a credential.
- The platform creates a short-lived credential and returns it.
- NebCLI writes that credential to the exact location the relevant standard tool reads from.
- The standard tool (
aws,kubectl,helm,git) runs on its own, using that credential. - 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 recovery from an expired principal or access credential has the same shape: a standard tool rejects the access, you run the matching nebcli ... refresh, and you retry the original command.
Planned managed executor credentials
A separate broker for platform-owned executor account material is planned, not delivered. Its authorization, custody, and enablement gates remain under review. That planned material can contain a refresh-bearing account file, so the short-lived principal and access claims above do not describe it.
Proving identity is not the same as being allowed
Before NebCLI brokers a principal or access credential, 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 delivered 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.