What Are GitHub Actions Secrets?
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform, built into the popular GitHub platform. It uses workflows to build and test every pull request to a GitHub repository, and can deploy merged pull requests to production.
GitHub secrets are encrypted environment variables, managed within GitHub Actions. They allow you to store sensitive data, like access tokens and credentials, in a secure manner. Secrets can be stored at the level of a specific GitHub repository, environment, or entire organization. They are only accessible to GitHub Actions workflows and authorized individuals.
Using GitHub secrets is a best practice for managing sensitive data in your projects. They offer a level of security that is important when working with third-party services, APIs, or login credentials. GitHub Actions secrets are not exposed in logs or scripts, making them a safe way to handle data that you wouldn’t want to be publicly accessible.
This is a part of a series of articles about secret management.
In this article:
How To Create GitHub Actions Secrets
Creating Secrets for a Repository
To create a secret for a repository, you need to navigate to the main page of the repository, then click on the Settings tab. From there, select Secrets and variables for the Actions from the left sidebar, and finally, click on the New repository secret button.
In the Name field, you should input the name of your secret. Remember, it should be descriptive and easily identifiable. In the Secret field, you need to input the actual secret data. Once you’re done, click on Add secret to save the secret.
Source: GitHub
Creating Secrets for an Environment
Creating secrets for an environment follows a similar process. From the Settings tab, select Environments from the left sidebar. Then, click on the name of the environment you want to add secrets to. Click on Add secret, and you’ll be presented with the same interface as when adding secrets to a repository.
Environment secrets are scoped to specific environments. This means that you can have different secrets for different environments, like staging and production, offering an extra layer of control over your sensitive data.
Note: Environments are only available for public repositories.
Creating Secrets for an Organization
Lastly, you can also create secrets at the organization level. These secrets are accessible to all repositories within the organization. To create an organization secret, you need to navigate to the main page of the organization, then click on Settings. From there, select Secrets and variables from the left sidebar (this should fall under the Security section). Next, select Actions and then the Secrets tab, and then click on the New organization secret button.
Creating an organization secret offers a centralized way to manage secrets for multiple repositories. However, it’s important to remember that these secrets can be accessed by all repositories within the organization, so they should be used judiciously.
Tips From the Expert
In my experience, here are tips that can help you better manage GitHub Actions secrets:
-
Use GitHub secret scanning tools
Regularly scan your repositories for accidental secret exposure using GitHub’s built-in secret scanning feature or third-party tools like TruffleHog. This can help catch and revoke secrets that may have been inadvertently committed. -
Automate secret rotation with CI/CD pipelines
Integrate secret rotation directly into your CI/CD pipeline using tools like HashiCorp Vault or AWS Secrets Manager. This ensures secrets are regularly refreshed without manual intervention. -
Utilize repository-specific secrets
Instead of using organization-level secrets for every repository, scope secrets down to individual repositories wherever possible. This reduces the exposure of secrets across multiple projects and enhances security. -
Use self-hosted runners for sensitive workflows
If dealing with extremely sensitive information (e.g., production API keys), consider running workflows on self-hosted runners instead of GitHub’s shared runners. This helps isolate sensitive jobs from shared infrastructure. -
Encrypt secrets outside GitHub for additional security
Consider using external encryption services like AWS KMS or GCP Cloud KMS to encrypt sensitive data before storing it as GitHub secrets. This adds an additional layer of encryption beyond GitHub’s native security.
Example: Using GitHub Actions Secrets in a Workflow
Now that you know how to create secrets in the GitHub Actions interface, let’s see how to use them within a workflow. Consider a simple workflow that deploys a web app to AWS. You would need various AWS credentials, like the access key and secret access key, to authenticate your deployment. These credentials can be stored as secrets within your GitHub repository.
In your workflow file, you would reference these secrets as follows:
steps:
- name: Deploy to AWS
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
...With this setup, your AWS credentials are kept secure and are not exposed in your workflow file or logs.
4 Best Practices in Managing GitHub Actions Secrets
Here are a few best practices that can help you manage GitHub Actions secrets effectively and securely.
1. Use GitHub’s Role-Based Access Control (RBAC) to Restrict Access
One of the first steps to securing GitHub Secrets is through the use of GitHub’s Role-Based Access Control (RBAC). RBAC allows you to grant specific permissions to different users based on their roles. This way, you can limit who has the power to create, view, or modify secrets, thereby reducing the risk of accidental or malicious exposure.
With RBAC, you can assign permissions at the repository, organization, or enterprise level. This flexibility ensures that only the necessary individuals have access to secrets, and you can easily revoke access whenever necessary. As a rule of thumb, always adhere to the principle of least privilege (POLP), which states that a user should only have the minimum permissions necessary to perform their job functions.
Furthermore, with RBAC, you can segregate duties, ensuring that one single person does not have complete control over all aspects of a project. This additional layer of security can help prevent malicious activities and reduce the impact of human error.
2. Utilize Environment-Specific Secrets for Staging, Production, etc.
Another best practice in managing GitHub Secrets is to utilize environment-specific secrets. This technique allows you to differentiate between staging, production, and other environments. Different environments often require different configurations, and mixing them up could lead to severe consequences.
With environment-specific secrets, you can create a unique set of Secrets for each environment. For example, you might have different API keys for your staging and production environments. This way, even if a Secret from one environment is compromised, it doesn’t affect the other environments.
Moreover, environment-specific Secrets can help you streamline your deployment process. By using GitHub Actions with these Secrets, you can automate the configuration of your different environments, saving you time and reducing the likelihood of human error.
3. Use GitHub’s Audit Logs to Track Changes and Access to Secrets
One often-overlooked feature in GitHub is the use of audit logs. These logs keep track of various activities in your repository, including changes to and access of Secrets. By regularly reviewing these logs, you can identify any unusual activity and take action before it escalates into a security incident.
Audit logs can help you answer critical questions such as who accessed a secret, when it was accessed, and what changes were made. Furthermore, with GitHub’s advanced search features, you can filter the logs based on various parameters, making it easier to find the information you need.
Just as importantly, audit logs can serve as evidence in the event of a security incident. They provide a trail of actions that can help in investigations and in holding the right parties accountable. Therefore, it’s essential to retain these logs for an appropriate period and protect them from tampering.
4. Regularly Rotate and Update your Secrets
Finally, a crucial best practice is to regularly rotate and update your GitHub secrets. This practice minimizes the risks associated with secret leakage. If a secret is compromised, regular rotation ensures that the leaked Secret is only useful for a limited time.
Moreover, updating secrets regularly can help in keeping your systems secure. For instance, if you’re using API keys as secrets, vendors often update these keys to incorporate new security features or patches. By regularly updating your Secrets, you ensure that you’re always using the most secure versions.
Related content: Read our guide to Kubernetes secrets
GitHub Secret Management with Configu
Configu is a configuration management platform with strong integration to GitHub Actions. It’s comprised of two main components:
Configu Orchestrator
As applications become more dynamic and distributed in microservices architectures, configurations are getting more fragmented. They are saved as raw text that is spread across multiple stores, databases, files, git repositories, and third-party tools (a typical company will have five to ten different stores).
The Configu Orchestrator, which is open-source software, is a powerful standalone tool designed to address this challenge by providing configuration orchestration along with Configuration-as-Code (CaC) approach.
Configu Cloud
Configu Cloud is the most innovative store purpose-built for configurations, including environment variables, secrets, and feature flags. It is built based on the Configu configuration-as-code (CaC) approach and can model configurations and wrap them with unique layers, providing collaboration capabilities, visibility into configuration workflows, and security and compliance standardization.
Unlike legacy tools, which treat configurations as unstructured data or key-value pairs, Configu is leading the way with a Configuration-as-Code approach. By modeling configurations, they are treated as first-class citizens in the developers’ code. This makes our solution more robust and reliable and also enables Configu to provide more capabilities, such as visualization, a testing framework, and security abilities.
