{"id":69409,"date":"2023-01-11T08:00:11","date_gmt":"2023-01-11T16:00:11","guid":{"rendered":"https:\/\/github.blog\/?p=69409"},"modified":"2023-01-13T18:53:08","modified_gmt":"2023-01-14T02:53:08","slug":"passwordless-deployments-to-the-cloud","status":"publish","type":"post","link":"https:\/\/github.blog\/enterprise-software\/devsecops\/passwordless-deployments-to-the-cloud\/","title":{"rendered":"Passwordless deployments to the cloud"},"content":{"rendered":"

Security is top of mind for us all in software development. My colleague, Mark Paulsen, recently shared a number of examples to mitigate OWASP vulnerabilities<\/a> while maintaining your developer experience and productivity.<\/p>\n

The security of the applications we\u2019re building is important. But we also need to consider the security of the hosting environments that we\u2019re deploying to. When deploying somewhere, you typically need to provide several pieces of information to enable the deployment to take place. Think of your cloud provider. You may need to be authenticated using a service principal, authorized using role-based access control, and the name of a project or an ID to a subscription, or some additional resource metadata.<\/p>\n

And here lies the challenge. You will typically have tens, possibly hundreds of service principals depending on the size of your application environment (also assuming you\u2019ve adopted the principle of least privilege). Each of those service principals would have its own password or certificate, which would then be used to authenticate to the cloud provider.<\/p>\n

Cryptographic failures is in position #2 of the OWASP 2021 Top 10 list<\/a> (which would encompass scenarios like secret or certificate leaks, weak passwords, and hardcoded passwords). IBM\u2019s Cost of a data breach 2022 report<\/a> explains that stolen\/lost credentials were the most common cause of a data breach and also took the longest to identify.<\/p>\n

So, what happens if one of your passwords or certificates leaks? GitHub Advanced Security\u2019s secret scanning <\/a>can identify exposed secrets in your codebase. With push protection<\/a>, you can be proactive and prevent secrets from being committed in the first place. In case you missed it, push protection now also covers custom patterns which you have defined<\/a>!<\/p>\n

But what about the best practice of regularly rotating the passwords\/certificates associated with each of those service principals? How do you keep references of those secret materials up to date in your CI\/CD tool? There is a fair amount of operational complexity involved in just maintaining secrets and access between your tools of choice.<\/p>\n

From a Site Reliability Engineering (SRE) perspective, this overhead could be considered as toil based on the characteristics defined in Google\u2019s Site Reliability engineering book<\/a>. Toil is unavoidable. But in the context of this blog post, we have the opportunity for optimization. While there are tools like Hashicorp Vault, which can help you organize, automate and maintain your secrets, wouldn\u2019t it be better if you could avoid the problem overall. What if you didn\u2019t have to use secrets to deploy to your preferred cloud provider?<\/p>\n

Fortunately, that\u2019s something we\u2019ve been working on at GitHub. Back in 2021<\/a>, we announced that GitHub enables you to deploy to your cloud provider using OpenID Connect. In this post, I\u2019ll provide you with a deeper overview of this functionality and how it can reduce operational complexities by removing the need for passwords.<\/p>\n

What is OpenID Connect (OIDC)?<\/span><\/a><\/h2>\n

Let\u2019s start by making sure we\u2019re all on the same page. Open ID Connect<\/a> is an authentication protocol, built on top of the OAuth 2.0 framework<\/a> (an authorization protocol). An ID token is usually returned from an authorization endpoint by using a sign-on flow.<\/p>\n

This ID token is served in the JSON Web Token (JWT)<\/a> standard, and typically digitally signed. As a result, this token can be used to verify the identity of the caller, and retrieve additional claims (think of these as additional properties, or statements about the entity) as well.<\/p>\n

You can find an example of an ID token returned from GitHub Actions below:<\/p>\n

{\n  \"typ\": \"JWT\",\n  \"alg\": \"RS256\",\n  \"x5t\": \"example-thumbprint\",\n  \"kid\": \"example-key-id\"\n}\n{\n  \"jti\": \"example-id\",\n  \"sub\": \"repo:octo-org\/octo-repo:environment:prod\",\n  \"environment\": \"prod\",\n  \"aud\": \"https:\/\/github.com\/octo-org\",\n  \"ref\": \"refs\/heads\/main\",\n  \"sha\": \"example-sha\",\n  \"repository\": \"octo-org\/octo-repo\",\n  \"repository_owner\": \"octo-org\",\n  \"actor_id\": \"12\",\n  \"repository_visibility\": private,\n  \"repository_id\": \"74\",\n  \"repository_owner_id\": \"65\",\n  \"run_id\": \"example-run-id\",\n  \"run_number\": \"10\",\n  \"run_attempt\": \"2\",\n  \"actor\": \"octocat\",\n  \"workflow\": \"example-workflow\",\n  \"head_ref\": \"\",\n  \"base_ref\": \"\",\n  \"event_name\": \"workflow_dispatch\",\n  \"ref_type\": \"branch\",\n  \"job_workflow_ref\": \"octo-org\/octo-automation\/.github\/workflows\/oidc.yml@refs\/heads\/main\",\n  \"iss\": \"https:\/\/token.actions.githubusercontent.com\",\n  \"nbf\": 1632492967,\n  \"exp\": 1632493867,\n  \"iat\": 1632493567\n}\n<\/code><\/pre>\n
In the context of this blog post, we can use OpenID Connect in GitHub Actions<\/a> to generate an ID token for us. This token is signed by GitHub and provides claims on the context of the workflow being executed (for example, the repository details, run number, actor that called the workflow, etc.).<\/p>\n
As a result, a cloud provider can then use this ID token to verify the authenticity of a request, allowing a \u2018trade\u2019 of the GitHub ID token for a short-lived access token.<\/p>\n

\n\u200b\u200b\"Diagram
<\/div>\n
Without OpenID Connect, you would typically have to pass in some credentials to your CI\/CD tool, so that it can authenticate to your cloud provider.<\/p>\n
GitHub Actions uses OpenID Connect to enable a workflow to authenticate against the cloud provider directly, without needing to use a password or a certificate. Instead, the access token from the cloud provider can be used.<\/p>\n
Throughout this process, you are effectively establishing a \u2018trust\u2019 between GitHub and a service principal in your cloud provider. In AWS, you would add an OIDC provider to IAM<\/a>, in Azure a \u2018Federated Identity Credential<\/a>\u2019 and then \u2018Workload Identity Federation<\/a>\u2019 in GCP.<\/p>\n
\n\n\n
Tip:<\/strong> this means that your cloud provider needs to support OpenID Connect as an authentication mechanism. There are several examples available in the GitHub docs<\/a>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/content-table-wrap><\/div>\n
Setting up your GitHub Action Workflow for OIDC<\/span><\/a><\/h2>\n
Whenever you execute a GitHub Action workflow run, a GitHub Token is created. You may have already referenced this token in your existing workflows using the ${{ secrets.GITHUB_TOKEN }}<\/code> expression. The GITHUB_TOKEN<\/code> is typically used to gain access to the needed parts of GitHub for your automation\u2019s needs.<\/p>\n
For example, if your workflow is publishing a new package, then you may need write permissions to GitHub Packages. If you\u2019re adding a comment to a GitHub Issue, then you would need write permissions to issues. Check out the GitHub docs for full details on permissions for the GITHUB_TOKEN<\/a>.<\/p>\n
To generate a GitHub OIDC ID token within your workflow, you\u2019ll need to explicitly give the GITHUB_TOKEN<\/code> permission to do this. This is done by setting the permissions for the id-token<\/strong> to write<\/strong>, as demonstrated in the snippet below.<\/p>\n
permissions:\n  id-token: write # This is required for requesting the JWT\n<\/code><\/pre>\n
This permission can be set either at the overall workflow level, or an individual job level. This will depend on where you need to use the token in your workflow (that is, across  multiple jobs, or just one job\u2014 remember, principle of least privilege\u2014only give the GITHUB_TOKEN<\/code> the access it needs!).<\/p>\n
Once this step is complete, your GitHub Action workflow will be capable of requesting the OIDC ID token, as outlined in the next section.<\/p>\n
Authenticating to the cloud provider using the GitHub OIDC token<\/span><\/a><\/h2>\n
If you already use GitHub Actions to deploy to the cloud, then you may be aware that there are several GitHub Actions that you can use to authenticate to your cloud provider:<\/p>\n