Whether you’re administering or writing CI/CD pipelines, the responsibility for your software engineering team’s security posture falls right on your shoulders. Are you up for the task?
We see a lot of engineering teams having challenges keeping their environment secrets and credentials for CI/CD pipelines centrally managed by a few authorized administrators. Often engineers need to store them within CI/CD platforms because admins don’t have access or can’t set the right access control to prevent engineers from reading them too. These credentials need to be rotated after a specified amount of time. Engineering and admin teams need to either regularly manually rotate or develop auto-rotation tools so that the development platform doesn’t suddenly stop working. Another topic which comes up quite often is that engineering teams struggle to access private resources from the CI/CD vendor’s managed agents.
If your organization faces similar challenges, you will be interested in OpenID Connect (OIDC) for CI/CD platforms.
Leveraging OIDC with GitHub Actions and Azure Pipelines
Both CI/CD platforms can act as an intermediate source of trust, also known as OpenID Provider. In the registration process of runners/agents a trust relationship is formed which is backed up by a certificate-based authentication. Based on that relationship GitHub Actions and Azure Pipelines issue a signed Identity Token to registered build runners/agent including specific claims like repository name, branch and other details of the workflow run. The job of the runner/agent is therefore a user by the means of OIDC.
59% of organizations aren’t revoking credentials that are no longer needed, meaning passwords can go unattended and dormant like a sitting duck.
This Identity Token can now be used for login and retrieving an Access Token at an Identity Provider (authentication). The Access Token will then be used by the agent/runner to access remote resources (authorization). In the case of Azure this token can be used directly in REST API calls or be provided to well-known tools like Azure CLI and Terraform ARM Provider. The Identity Provider for accessing Azure Resources is Microsoft Entra ID (formerly Azure Active Directory).
For the login of the agent/runner to succeed, first a trust relationship between the OpenID Provider and the Identity Provider needs to be formed. This can be done through Microsoft Entra ID for a Service Principal or a Managed Identity and is called Workload Identity Federation. There are several step-by-step manuals for Azure Pipelines and GitHub Actions to set up the trust relationship.
Credential exposures can stem from many factors: Plain text passwords, weak cryptography, flawed CI/CD or packaging automation and compromised developer accounts or malicious insiders.
This process doesn’t need any credentials or secrets to be saved or managed by your organization or engineers, it is purely relying on GitHub Actions or Azure Pipelines to verify the identity of an agent/runner and attest this with the Identity Token. Even going further including claims specifically for the current CI/CD job. The Identity Token can then be verified by the Identity Provider (here Microsoft Entra ID). These tokens are all short lived and if exposed only usable for a short amount of time. In contrast credentials like secrets or certificates need to be revoked, changed and rotated in case they get exposed. The described mechanism brings CI/CD platforms closer to modern Zero Trust principles like “Never trust, always verify” – all tokens involved will be generated and verified for every job.
On top of the above benefits, it is now also possible to control the access even more fine-grained than with a traditional secret-based authentication. A common scenario would be to only allow a specific CD job running on the default or a release branch to modify Azure resources. Same CD job on a development branch would be denied access to the production environment or could just receive access to modify the development environment instead.
Access to Hybrid and Private Cloud
OIDC can also be used in hybrid scenarios with other cloud providers. GitHub is already leveraging the Identity Tokens to get access to their private cloud resources without the need to construct error prone VPN connections and configurations. They also opened sourced their OIDC Gateway component which can be adapted to access private clouds from managed CI/CD Runners and Agents.
Conclusion
OpenID Connect is a powerful protocol extension of OAuth2.0 which can be used to connect and access resources without the need for error prone network setup or the need for storing and managing credentials within CI/CD platforms like GitHub Actions and Azure Pipelines. Therefore, software engineers can’t accidentally leak credentials. It is based on configurable trust relationships and short-lived Identity and Access Tokens. It also eliminates the need to maintain self-hosted Runners or Agents so that software engineering teams can focus on new features for their services instead of maintaining a fleet of Runners or Agents.
