I am setting up a CI/CD pipeline for a public open-source project on GitHub, and I need to use sensitive API keys for our integration tests. I am terrified of accidentally committing these credentials to the repository or having them exposed in the build logs. What is the most secure way to manage secrets in GitHub Actions or similar tools? I've heard about "Environment Secrets," but are they enough to prevent a contributor from maliciousy printing them out during a Pull Request?
3 answers
For public repositories, you must use GitHub "Actions Secrets" combined with "Environments." Environments allow you to require manual approval from a maintainer before any secrets are injected into a workflow triggered by a Pull Request from a fork. This prevents a random contributor from adding echo $SECRET to a script and stealing your keys. Additionally, GitHub automatically masks secrets in the logs, replacing them with asterisks. However, for maximum security, consider using a dynamic secret provider like HashiCorp Vault or AWS Secrets Manager to generate short-lived credentials.
Have you looked into using "OpenID Connect" (OIDC) so that you don't have to store long-lived cloud credentials in GitHub at all?
Always use .gitignore for local testing and never, ever hardcode keys. Use Environment variables locally and Secrets in the cloud. Simple but effective.
Great advice, Karen. I'd also add that using a tool like "trufflehog" in your pipeline can scan your commits to make sure no one accidentally bypassed the .gitignore file.
Brian, OIDC is a game changer. Instead of storing an AWS_SECRET_ACCESS_KEY, GitHub can request a short-lived token directly from AWS using a trusted relationship. This means even if your GitHub account was somehow compromised, there are no static passwords to steal. It significantly reduces the "blast radius" of a potential security breach. I highly recommend checking out the official GitHub documentation on configuring OIDC with cloud providers.