From secret to least privilege
This is the Learning Atlas from Orbit. Get your invite
Misc tech termsConcepts and methodologyGit fundamentals
-
Step 1: Secret
Why this matters here
Begin with the broad idea of a secret so the learner can recognize many sensitive values before focusing on one credential format.
What it is
A secret is any value that should be known only to the people or systems authorized to use it. The label describes how the value must be handled, not one particular format: API keys, credentials, personal access tokens, and private signing material can all be secrets. A secret belongs in controlled storage and delivery paths, never in a committed source file.
When you’d use it
You use the concept of a secret whenever a value could let someone impersonate a service, access private data, or incur cost if it became public.
-
Step 2: API key
Why this matters here
An API key makes the abstract risk concrete: it shows how a secret authenticates a machine-to-machine request and can carry real cost or access.
What it is
An API key is a service-issued credential for identifying a program or integration. It is often sent in a request header or query parameter, so anyone who obtains it may be able to act within its configured permissions and spend the owner's quota. Treat an API key as a secret, keep it out of source control, and prefer narrow scopes where the provider supports them.
When you’d use it
You use an API key when a server-to-server integration needs to authenticate requests without a user interactively signing in for every call.
-
Step 3: Environment variable
Why this matters here
Environment variables introduce a practical way to deliver configuration at runtime without copying credentials into tracked source files.
What it is
An environment variable separates configuration from source code: a program reads a name such as `API_KEY` at runtime instead of embedding the value in a tracked file. That separation reduces accidental commits, but it does not make a value harmless—process listings, logs, crash reports, shell history, or an overly broad deployment can still expose it.
When you’d use it
You use environment variables when the same code must run with different credentials or settings across a laptop, test environment, and production deployment.
-
Step 4: .gitignore
Why this matters here
The ignore file establishes a repository boundary before the learner sees the harder lesson that prevention only works before a secret is committed.
What it is
The .gitignore file contains a list of patterns outlining which files or directories Git must completely ignore. This prevents massive, auto-generated, or highly sensitive files from cluttering the repository or accidentally leaking into the public commit history.
When you’d use it
You set up a .gitignore file at the very start of a project to ensure private data, personal IDE settings, and compiled binaries stay strictly on your local machine.
-
Step 5: Git history
Why this matters here
Git history exposes why deletion is not erasure, making the persistence of an accidental commit visible before incident response begins.
What it is
Git history is the chain of commits that records how a repository changed over time. Deleting a file does not remove its earlier contents from history, and adding a path to `.gitignore` afterward does nothing retroactively. If a secret was committed, the old commit can still expose it even after the file disappears from the latest version.
When you’d use it
You inspect Git history during incident response, code review, or cleanup whenever sensitive data may have been committed, because the current checkout is only one snapshot of the repository.
-
Step 6: Revoke
Why this matters here
Revocation comes first in response because an exposed credential must be made unusable before cleanup and replacement can be trusted.
What it is
Revoking access is the immediate containment action for a lost, exposed, expired, or no-longer-needed credential. It tells the issuing service to reject the value, but it does not erase copies from logs, tickets, local files, or Git history; those copies still need cleanup and the replacement credential must be handled safely.
When you’d use it
You revoke first when a credential may be in an unauthorized person's hands, then investigate the exposure and rotate the access that still needs to exist.
-
Step 7: Rotation
Why this matters here
Rotation follows revocation by showing how to restore the access that is still needed with a fresh value and a controlled cutover.
What it is
Credential rotation changes the value used for access while preserving the service's intended function. A safe rotation creates or enables the replacement, updates every authorized consumer, verifies the new value, and then revokes the old one. Rotation limits how long a leaked or overexposed credential remains useful.
When you’d use it
You rotate a credential when its exposure, age, ownership, or policy requires a fresh value without leaving an avoidable access gap.
-
Step 8: Vault
Why this matters here
Once the replacement exists, a Vault gives it a deliberate home instead of moving the same secret back into source files or chat.
What it is
The Vault is project-agnostic — keys added once are available everywhere in Orbit. Each key has a name (what Orbit calls it internally) and a value (the actual secret). Keys are encrypted on write and never leave your machine. BYOK keys bypass the Sivants Credits system entirely for that provider — Orbit calls the provider directly using your key.
When you’d use it
You set up the Vault during initial Orbit configuration, then add keys as needed for new services.
-
Step 9: Least privilege
Why this matters here
Least privilege closes the loop by reducing what the next credential can reach, limiting the blast radius when prevention or handling fails.
What it is
Least privilege reduces the damage a compromised credential can cause by narrowing its permissions, scope, data reach, and lifetime. It is more than choosing a read-only label: access should be specific to the task, separated between environments, reviewed as needs change, and removed when the task ends.
When you’d use it
You apply least privilege whenever you issue or review credentials, because limiting their blast radius makes mistakes and leaks easier to contain.