Give a deploy credential one narrow job

Separate automation and personal administration

A reporting API pipeline needs to select an approved artifact and invoke a controlled release action. That does not automatically require creating users, changing billing or reading every application secret. Begin with a permission inventory and a protected test environment; keep credentials out of documents, repositories and example logs.

Human recovery access should remain separate so revoking a deploy credential does not remove the only investigation path. Identify an authorized maintainer and independent host verification. A second unrestricted key is another credential, not a narrower role.

Describe the allowed operation precisely

Validate the release action's inputs. A restricted command that concatenates arbitrary text into a privileged shell still permits unintended work. Review wrapper behavior, writable paths and artifact trust together. Broad sudo privileges or access to the Docker socket can defeat the intended boundary.

Treat workflow edits as credential access

Someone able to change trusted workflow steps may use or expose their credentials. Review repository permissions, protected deployment environments and which events run privileged jobs. Keep production credentials away from untrusted pull-request code. Give a workflow token only the permissions its job needs.

GitHub recommends full-length commit SHA pinning for immutable action selection. Review the selected action and later updates; a version tag can move. Avoid inserting untrusted event data directly into inline shell code. Masking known secret values is not a guarantee against disclosure through transformations, logs or artifacts.

Technical reference: GitHub Actions secure use.

Use short lifetime when the destination supports it

OpenID Connect can let a supported destination exchange workflow identity for a short-lived credential. Configure trust checks for the intended repository, branch or environment and audience. This is neither a universal SSH replacement nor a feature supplied by the current PrivacyNodes frontend.

If your deployment uses SSH, review the installed package's authorized-key options. A forced command alone does not prohibit forwarding; restrictions must cover the intended access paths and still invoke a safe release operation. Test in a separate environment. Preserve working administration and recovery access while changing authentication, and verify a fresh independent connection before removing the old method.

Technical reference: GitHub Actions OpenID Connect · OpenSSH authorized_keys format.

Test permitted and forbidden work

Verify that the identity can select the intended artifact, invoke the release and obtain a useful result. Then test its limits: another application's secrets, unrelated file changes and arbitrary administration should be unavailable. Include artifact paths and arguments the wrapper must reject.

Record identity, scope, expiry where applicable, approving maintainer and audit-evidence location. Keep storage references rather than credential values. If a test only works after granting broad administration, revisit the release task instead of silently making that the permanent role.

Rehearse revocation and a broken-pipeline release

Prepare a replacement with the reviewed scope, verify a test deployment, switch the pipeline and revoke the old identity. Confirm the superseded credential fails and no duplicate remains in another workflow. Adding a new key alone does not remove previous access.

Document how an authorized maintainer halts deployment and recovers when CI is unavailable. Link that procedure to the release record and recovery inventory. A narrow credential limits intended authority; it does not make a malicious artifact harmless.