Continuous delivery workflows in GitHub Actions can deploy software, create and update cloud infrastructure, and use other services in a cloud provider, like Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), or HashiCorp.
As a part of our effort to make GitHub Actions easier and more secure, we are announcing general availability of GitHub Actions support for OpenID Connect (OIDC). Now that Actions supports OIDC, you can take a more secure cloud deployment approach by configuring your workflow to request a short-lived access token directly from the cloud provider. Many providers support OIDC, including AWS, Azure, GCP, and HashiCorp Vault.
OIDC + GitHub Actions =
Without OIDC, you would need to store a credential or token as an encrypted secret in GitHub and present that secret to the cloud provider every time it runs. The new OIDC support gives you a very clear separation of the configuration that you need to manage in GitHub and the permissions that you need to manage in the cloud portal, making cloud deployments simpler to set up and more secure.
No long-lived cloud secrets: You won’t need to add long-lived cloud credentials as GitHub secrets and worry about token expiry and rotating them. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
Authentication and authorization management: You have more granular control over which workflows can access cloud resources by using your cloud provider’s authentication (authN) and authorization (authZ) tools.
Rotating credentials: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single workflow job, and then automatically expires.
How it works
- Developers set up OIDC trust on their cloud roles to manage access between their deployment workflows and cloud resources.
- In each deployment, a GitHub Actions workflow can now mint an auto-generated OIDC token. This token has all the metadata needed to get a secure, verifiable identity for the workflow that’s trying to authenticate.
- Cloud login actions can fetch this token and present it to their respective clouds.
- The cloud provider then validates the claims in the OIDC token against the cloud role definition and provides a short-lived access token. Actions and steps within the same workflow job can use this access token to connect and deploy to the cloud resources. The token expires when the workflow job completes.
Get started today
To make it easy to use OIDC to deploy, we have worked with popular cloud partners, like AWS, Azure, GCP, and HashiCorp to add OIDC support to their official login actions. Learn more about how you can secure your cloud deployments by using OIDC. Additionally, check out our GitHub Universe talk on Open ID Connect (OIDC) support in GitHub.
Tags:
Written by
Related posts
Execute commands by sending JSON? Learn how unsafe deserialization vulnerabilities work in Ruby projects
Can an attacker execute arbitrary commands on a remote server just by sending JSON? Yes, if the running code contains unsafe deserialization vulnerabilities. But how is that possible? In this blog post, we’ll describe how unsafe deserialization vulnerabilities work and how you can detect them in Ruby projects.
10 years of the GitHub Security Bug Bounty Program
Let’s take a look at 10 key moments from the first decade of the GitHub Security Bug Bounty program.
Where does your software (really) come from?
GitHub is working with the OSS community to bring new supply chain security capabilities to the platform.