A deployment workflow can access powerful credentials. Limit each secret to the jobs and environments that need it, and treat build logs and artifacts as possible disclosure paths.
IN THIS ARTICLE
What you need before you begin
List the credentials used by the workflow and who can change the code that runs in each job. Identify untrusted contribution or pull-request paths.
01 Protect production secrets in CI jobs
Store secrets in the CI platform’s protected secret or environment mechanism. Keep them out of repository files and ordinary workflow variables intended for public configuration.
Separate build credentials from production deployment credentials. Grant the smallest useful permissions and use short-lived identities where the platform and target support them.
Restrict which branches or reviewed deployment paths can access production secrets. Do not expose them to untrusted code merely because a workflow is triggered automatically.
Avoid echoing secrets, full environment dumps or commands that include credentials in their arguments. Masking is helpful but cannot guarantee every transformed value remains hidden.
Review generated artifacts and logs before sharing them. Rotate credentials after a suspected disclosure and record their owners and expiration.
Confirm the expected result
Confirm a normal build works with only its required access and a non-deployment job cannot obtain production credentials. Test revocation and replacement in a controlled environment.
Troubleshoot unexpected results
If a secret is absent in a job, check environment, event and permission rules before copying it into the workflow file. Those boundaries may be working as designed.
A common question
Are encrypted CI secrets safe from any workflow code?
A job that receives a secret can use or disclose it. Control who can change that job and what untrusted code it executes, as well as where the value is stored.