Password-less Authentication in 2023: Cloud Security with OpenID Connect

Mergify is a beacon of innovation, ever in pursuit of excellence. We champion processes that not only optimize workflows but also enhance security. GitHub Actions have been instrumental in driving our automation forward – a pivotal tool for end-to-end testing, database migration testing, and rendering pull request preview environments. However, with growth comes a responsibility to ensure our operations' safety. This responsibility prompted us to delve deeper and rethink traditional security approaches, especially concerning cloud integration.

Traditional Security: A Close Examination

The classic way of setting up tasks entails creating a dedicated service account with cloud service providers and crafting an API key for connectivity. On the surface, this process seems simple, efficient, and practical. However, the underbelly of this method exposes vulnerabilities.

Despite their utility, these API keys are akin to ticking time bombs. If, for some reason, an API key gets leaked, the aftermath could be catastrophic—a virtual open door for malicious entities to access sensitive databases and cloud storage. While the standard industry practice recommends rotating these credentials every 60-90 days, this is an eternity in the world of cyber threats. The window of vulnerability that these intervals present can be exploited, and the repercussions can be grave.

It's the dawn of 2023. Our question was simple yet profound:

Is there not a better, more fortified way?

Breaking Barriers with OpenID Connect

Our relentless pursuit of superior security mechanisms led us to the doorstep of OpenID Connect and the promising domain of Workload Identity Federation.

What Exactly is OpenID Connect?

Originating from the robust foundation of the OAuth 2.0 protocol in 2014, OpenID Connect emerged as a beacon, offering password-less authentication flows between two providers deemed trustworthy.

This shift was monumental.

AWS, recognizing the potential, integrated this protocol in February 2021. Hot on its heels, Google Cloud Platform did the same in April. The stage was already set when GitHub, in an empowering move in October, integrated the capability to generate and validate OpenID Connect JWTs. This amalgamation opened floodgates, heralding a new era of authentication between GitHub Actions and a myriad of Cloud Providers.

In September 2021, AWS tooling was updated to support it, and Google released a new GitHub action to use this new authentication mechanism.

A Detailed Walkthrough: The Mechanism in Action

With the backdrop set, let's delve into the mechanics of this groundbreaking shift. The base remains unchanged—a cloud service account with the set of permissions your workload requires, for example,
getting access to an Object Storage bucket. Yet, the transformation is radical: this account lacks passwords or credentials. Here's a step-by-step breakdown:

1. Configuring the GCP Identity Provider: This initial step involves granting GitHub the permissions to act (or impersonate) your service account under specific, pre-defined criteria.
2. Setting up a Workflow Identity Pool: Link this with GitHub's "OIDC Connect Issuer URL." Here, one must outline the exact criteria that permit password-less authentication. For instance, allowing impersonation if the repository owner is "Mergifyio."
3. Crafting the JWT Token: As tasks are executed, GitHub Actions meticulously craft a JWT token infused with metadata. This token contains the organization, repository, actor, GitHub workflow references, and event type.
4. The Role of GCP's IAM: This entity verifies the token's origin, cross-referencing the embedded metadata against the criteria set in the Workload Identity Pool. A time-bound (1-hour) token is generated and relayed to the GitHub Workflow upon successful validation.

This intricate dance of authentication and verification is made seamless through automation. GitHub actions like Google's auth and AWS's configure-aws-credentials are prime examples where you must set only the pool ID and name of the service account you want to impersonate.

This GCP GitHub action describes all the resources needed to set up the OIDC Connect password-less authentication with GCP. AWS also provides resources to prepare everything.

GitHub also offers examples of setups for many cloud providers to do the setup: AWS, Azure, Google Cloud Platform, HashiCorp Vault, and more.

Kickstarting Your Journey: A Treasure Trove of Tips

Embarking on this journey towards superior security? We've curated a list of expert tips to ensure a seamless transition:

• Permission Prerequisites: Your GitHub Workflow must have the id-token: write permission, essential for crafting the OIDC Connect JWT.

permissions:
  id-token: write # This is required for requesting the JWT

• GCP Role Allocation: For GCP aficionados, ensure that your service account is endowed with the roles/iam.workloadIdentityUser role.
• Diversify Service Accounts: Consolidating all tasks under one service account is a relic of the past. Modern best practices advocate dedicating separate accounts for distinct workflows—ideally, one per repository or even one per GitHub Workflow.

Mergify's Vision for the Future

Our mission is crystal clear: methodically phase out our dependency on the conventional secret-storing mechanisms. Our successful integrations with GCP, AWS, and PyPI are testaments to our dedication. Now, with bated breath, we await Heroku's adoption of OIDC.

In today's tech ecosystem, security is more than just a feature; it's a covenant with our users. We invite you to join us as Mergify blazes the trail toward a more secure future. It's not merely about adopting new tools but about championing an ethos of unparalleled safety and functionality in the digital realm.

Together, let's shape the future of tech security.