OpenID-based security features added to GitHub Actions as usage doubles

Single-use tokens and reusable workflows explained at Universe event

GitHub Universe GitHub Actions have new security based on OpenID, along with the ability to create reusable workflows, while usage has nearly doubled year on year, according to presentations at the Universe event.

The Actions service was previewed three years ago at Universe 2018, and made generally available a year later. It was a huge feature, building automation into the GitHub platform for the first time (though rival GitLab already offered DevOps automation).

It require compute resources, called runners, which can be GitHub-hosted or self-hosted. Actions are commands that execute on runners. Jobs are a sequence of steps that can be Actions or shell commands. Workflows are a set of jobs which can run in parallel or sequentially, with dependencies. For example, that deployment cannot take place unless build and test is successful. Actions make it relatively easy to set up continuous integration or continuous delivery, particularly since they are cloud-hosted and even a free plan offers 2,000 automation minutes per month, and more than that for public repositories.

In order to deploy, or access resources such as databases for testing purposes, Actions need to authenticate against those resources. A common approach is to use encrypted environment variables but there are several hazards, such as secrets getting inadvertently logged in plain text, as well as the problem of credentials going out of date and having to be updated.

The solution is OIDC (OpenID Connect) tokens, which means requesting a one-time token from a cloud provider. Providers include AWS, Azure, Google Cloud Platform, and HashiCorp Vault. A step or Action in the workflow can request this token. Usage of OIDC is documented here with specific guides for the four providers mentioned above.

OpenID Connect architecture for GitHub Actions

Another benefit of OIDC is that permissions can be made more granular by configuring conditions for issuing tokens. An example given in a Universe presentation by product manager Jennifer Schelkopf is that staging job can be configured without access to the production environment, which could be reserved for a second "deploy to production" job.

Another new feature in Actions is reusable workflows, currently in beta. The idea is to be able to call one workflow from another, as easily as using an Action with the uses statement. A reusable workflow has to specifically support being called in this way, via a workflow_call event which receives inputs including secrets from the calling workflow. The advantage is less use of "clipboard inheritance".

A simple reusable workflow

There are some limitations, like no nesting (a reusable workflow cannot call another reusable workflow). Environment variables are not propagated but would have to be passed as inputs. During the beta, the caller workflow cannot access the outputs from a called workflow, but this will be fixed for general availability. Documentation is here.

GitHub Actions usage has increased from 75 million jobs per month, reported at Universe 2020, to over 147 million jobs per month reported at the current event. In addition, the number of actions in the GitHub marketplace has increased from 6,200 a year ago to 10,431 at the time of writing. Any vendor who provides cloud services or tools benefits from providing Actions that make it easy to automate their use. A quick search reveals 300 AWS actions, for example (most unofficial), and 136 for Azure. There are also actions for things like Slack and Teams notifications, security scanning, and for numerous deployment platforms.

What else is coming for Actions? The first place to look is the GitHub roadmap, which shows to some degree what is on the way. One welcome planned feature is the ability to use Actions from internal repositories other than the one where the workflow is hosted. ®