Managing Secrets and Environment Variables

Pipelines need tokens and passwords to reach registries and cloud targets. Hardcoding them leaks them to anyone with repo access — that’s what secrets prevent.

You add secrets in repository, organization, or environment settings. They’re encrypted at rest and exposed to workflows only as masked values.

Reference a secret through the secrets context, then pass it into a step as an env var or action input. Here it feeds a deploy script.

GitHub auto-masks secrets in logs as ***. Even so, never echo or persist one — transforms like base64 can slip past the mask and leak it.

For non-sensitive config like a region or build flag, use variables via the vars context. They’re visible in the UI, which is fine when nothing’s secret.

Every run gets an automatic GITHUB_TOKEN to authenticate to the repo. Scope it tightly with the permissions key — least privilege.

An environment like staging or production groups secrets and adds protection rules — required reviewers, wait timers, branch limits — before a deploy runs.

With a protected environment, a deploy job pauses until a designated reviewer approves — a deliberate human gate in front of production.

Secrets are never passed to workflows from forked PRs, so an untrusted contributor can’t steal them. Design CI so fork PRs need no secrets.

Treat every secret as rotatable. When one leaks or expires, just update it in settings — the next run picks up the new value, zero code changes.

The playbook: secrets for sensitive values, variables for the rest, a tightly scoped GITHUB_TOKEN, environments guarding production, and never log a secret.

Secret or variable, masked or visible — which goes where?

You can manage secrets and variables safely now: store them encrypted, read via the secrets context, scope the token, and gate deploys behind environments.