GitHub Actions: secure self-hosted runners by limiting them to specific workflows
You can now enforce consistent usage of self-hosted runner groups across your organization and enterprise.
Over the last few months, we’ve made it easier for large organizations to improve the consistency and security of their CI/CD workflows using GitHub Actions. For example, you can create reusable workflows, share actions and reusable workflows within your enterprise, or secure your deployments with OpenID Connect. Today, we’re taking things a step further.
We’re excited to announce an enhancement to the self-hosted runners experience that improves the security of your CI/CD workflows. Many organizations today have secrets stored on their self-hosted runners in order to enable production deployments or other highly-privileged workflows. Previously, any workflow in the repository, such as an issue labeller, could access these runners, but that’s no longer the case. Now, admins can pick which specific workflows can access a runner group. This is a great way to secure your deployments if you aren’t ready to adopt OpenID Connect.
When combined with reusable workflows, this feature enables admins to enforce consistent usage of runner groups and workflows across their organization. For example, you can have a runner group with production secrets on it and require that everyone use it via a reusable deployment workflow. Other workflows in the organization can’t access these runners unless they also use the reusable deployment workflow. This allows you to standardize your deployment workflows, including the runners they use, for your entire organization.
Here’s how to set this up:
- Create a reusable workflow that describes the steps you want everyone to utilize when deploying to production.
- In the runner group settings, set Repository access to All repositories.
- In the runner group settings, set Workflow access to Selected workflows, and specify the reusable workflow you created.
Once these settings are saved, everyone in your organization will be able to use the production runner group, but only when executing the monalisa/automation/workflows/deployment.yaml reusable workflow at ref v1.
Learn more about workflow restrictions for self-hosted runner groups.
Tags:
Written by
Related posts
Try out OpenAI o1 in GitHub Copilot and Models
OpenAI o1-preview and o1-mini are now available in GitHub Copilot Chat in VS Code and in the GitHub Models playground.
Enhancing the GitHub Copilot ecosystem with Copilot Extensions, now in public beta
Whether you’re an individual developer looking to streamline your workflow or an organization aiming to integrate proprietary tools, GitHub Copilot Extensions now offers a platform to make that happen and to share your creations on the GitHub Marketplace.
First Look: Exploring OpenAI o1 in GitHub Copilot
We’ve tested integrating OpenAI o1-preview with GitHub Copilot. Here’s a first look at where we think it can add value to your day to day.