To do this, a workflow needs to authenticate itself to the cloud provider through credentials to gain access to those resources and services.
Up until now, you would create credentials in the cloud provider and then store them again hardcoded as Github secrets, which can be presented to the cloud provider to grant the workflow access and permissions every time the workflow runs. Github recently announced in their blog that deployments with OpenID Connect (OIDC) through Github Actions are now generally available. With OIDC, your workflows can securely deploy after obtaining a short-lived access token directly from the cloud provider without the necessity to store long-lived credentials as GitHub secrets. Actions can utilize this access token, which expires at job completion, to connect and deploy to the cloud provider. This approach is not only simpler but also more secure as it gives you more control over your workflows' permissions and lets you forget about synchronization, expiration, or rotation.
All the major players such as AWS, Azure, or GCP support OIDC. In this post, I show how to do it in AWS. To make it work, you first need to add a GitHub OIDC Provider (featuring its thumbprint) to a CloudFormation stack once (a single OIDC provider is enough to serve multiple roles). Audience/ClientId must be sts.amazonaws.com in this case because we will use the official action; however, in general, it can be the URL of a Github user or organization.