Lets gets started.<\/p>\n
Sample AWS Deployment Workflow With GitHub Actions<\/h2>\n
The following image gives you a context on how GitHub Actions interact with AWS services.<\/p>\n In the above workflow, we have used an example of GitHub actions workflow that interacts with AWS EKS to push images to ECR and deploy applications on EKS.<\/p>\n For the GitHub actions to interact with AWS services, it needs to authenticate with AWS. <\/p>\n Let’s look at the different ways you can access AWS services like an EKS cluster from GitHub Actions. This way you understand why OpenID Connect is secure than other methods.<\/p>\n The basic way to access EKS clusters from actions is by using AWS access and secret keys. <\/p>\n Here is an example workflow configuration.<\/p>\n But, storing or using AWS access and secret keys (long-lived tokens) directly in CI\/CD pipelines is considered insecure and not a recommended approach.<\/p>\n If these long-term credentials are leaked, anyone with access to them can potentially control your AWS resources, leading to data breaches or infrastructure compromise.<\/p>\n The recommended approach to overcome the limitations of using access keys and secrets is AWS IAM roles<\/a>. <\/p>\n IAM roles use Temporary security credentials. It is not stored with the user but are created dynamically and given to the user when needed. They can be set to last from a few minutes to several hours. <\/p>\n Once they expire, AWS no longer recognizes them or allows access through API requests made with them.<\/p>\n OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in AWS without needing to store AWS credentials as long-lived GitHub secrets. <\/p>\n This means that a GitHub Actions workflow can request a short\u2011lived OIDC token from GitHub, present it to AWS IAM, and get a temporary role. There is no need to store access keys in secrets.<\/p>\n Also, temporary credentials do not exist until a workflow needs them, and they expire shortly after (zero standing permissions).<\/p>\n OIDC can be used for both Github hosted runners and self-hosted runners.<\/p><\/blockquote>\n In this guide, our focus is only on the OpenID Connect based GitHub actions workflow with AWS.<\/p>\n Now, let’s look at a practical example, where I show you step by step how to configure OIDC with GitHub and AWS.<\/p>\n In this setup, GitHub is the OpenID\u202fProvider. So we need to setup the provider details on AWS. <\/p>\n Navigate to AWS IAM \u2192 Identity Providers.<\/p>\n Add a new provider:<\/p>\n If you click the created Identity provider<\/strong>, you will get an option to Assign role <\/strong>as shown below. <\/p>\n Click Assign role <\/strong>and select the create a new role option.<\/p>\n Next, select the trusted entity type “Web Identity<\/strong>” to log in to AWS with OIDC. <\/p>\n Now, enter the web identity information. Under Github Organization, enter your Github organization ID. <\/p>\n Next, add IAM permissions. Here, I am adding admin permissions. But as per your requirements and use cases, you can add only the required IAM permissions that your runner needs.<\/p>\n In the next page, enter the role name (eg, Now you need to add the role ARN to GitHub\u202fSecrets.<\/p>\n You have two choices:<\/p>\n Pick the option that fits your needs. For this demo, we\u2019ll set the secret at the organization level.<\/p>\n Navigate to the org or repo settings.<\/p>\n In the left pane you will find the secrets and variables option. Under secrets and variables, choose actions.<\/p>\n AWS_OIDC_ROLE<\/p>\n The next step is to validate the integration of OIDC with AWS.<\/p>\n The following action uses the To test this, we will create a simple GitHub Actions working to list AWS instances.<\/p>\n Create a If all the configurations are correct, when you run the workflow, you should be able to see the successful output as shown below.<\/p>\n Now that we have validated the OIDC AWS access using a workflow, we will test an EKS-based deployment using a workflow.<\/p>\n When setting up GitHub Actions to access an EKS cluster, you need to take several specific steps beyond basic AWS authentication. <\/p>\n This is because accessing an EKS cluster requires both AWS IAM permissions and Kubernetes-specific RBAC settings.<\/p>\n Next, we set up access policies for the arn to access Kubernetes objects.<\/p>\n You can list the available access polices using the following command.<\/p>\n Most runners would admin policy to deploy and manage the clusters. So, for testing purposes, I am going to assign AmazonEKSAdminPolicy <\/p>\n Here is an example of a GitHub Actions workflow that implements OIDC for AWS. I have used the In the above workflow, update the Role URL and cluster name before running it.<\/p>\n If you trigger the workflow manually, you will see the successful output as shown below. <\/p>\n Now that we have done the hands-on, let’s look at the whole workflow. It will make more sense to you now.<\/p>\n The following image shows the end-to-end workflow.<\/p>\n Here is how it works.<\/p>\n If the temporary token is valid for 1 hour and if GitHub Actions job finishes in 10 minutes, the temporary AWS credentials it obtained will still be technically valid for the remaining 50 minutes.<\/p><\/div>\n<\/div>\n You can also setup OIDC with self-hosted GitHub Enterprise servers.<\/p>\n When when working with GHES OIDC you need to consider the following.<\/p>\n Securing your CI\/CD pipelines is an important aspect of modern software development, especially when deploying applications to cloud environments like AWS. <\/p>\n By leveraging GitHub Actions OIDC for AWS, you can enhance the security of your workflows without the need for long-lived AWS credentials. <\/p>\n This approach not only mitigates the risks associated with access keys and secrets but also simplifies credential management through the use of temporary security credentials. <\/p>\n Now we would like to hear from you.<\/p>\n How do you manage credentials for AWS access through Github Actions?<\/p>\n Have you tried OIDC approach?<\/p>\n Do let us know in the comments.<\/p>\n![\"Example](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/ACTIONS-OIDC.png\")
<\/figure>\nUnderstanding AWS Authentication Methods for GitHub Actions<\/h2>\n
1. Access Keys And Secret Keys <\/h3>\n
- name: Configure AWS credentials\n uses: aws-actions\/configure-aws-credentials@v1\n with:\n aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}\n aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n aws-region: us-west-2<\/code><\/pre>\n2. For Self-Hosted Runners: Using IAM Roles<\/h3>\n
3. OpenID Connect (A Secure Approach)<\/h3>\n
Configuring GitHub Actions OIDC with AWS IAM<\/h2>\n
Step 1: Create the OIDC Identity Provider in AWS IAM for GitHub<\/h3>\n
![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-14.png\")
<\/figure>\n\n
\n
https:\/\/token.actions.githubusercontent.com<\/code><\/li>\nsts.amazonaws.com<\/code><\/li>\n<\/ul>\n<\/ul>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-19.png\")
<\/figure>\nStep 2: Create WebIdentity IAM Role with Trust Policy<\/h3>\n
![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-46.png\")
<\/figure>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-47.png\")
<\/figure>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-20.png\")
<\/figure>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-21.png\")
<\/figure>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-22.png\")
<\/figure>\ngithub-actions-workflow-role<\/code>), review the details and click create role.<\/p>\nStep 3: Add the IAM Role arn to Github<\/h3>\n
\n
![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-18.png\")
<\/figure>\n<\/p>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-23.png\")
<\/figure>\nStep 4: Testing the OIDC Connection to AWS<\/h3>\n
aws-actions\/configure-aws-credentials<\/code> action to configure OIDC in workflows. secrets.AWS_OIDC_ROLE<\/code> fetches the secret arn we created in the previous step.<\/p>\n- name: Configure AWS credentials using OIDC\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: ${{ secrets.AWS_OIDC_ROLE }}\n aws-region: us-west-2<\/code><\/pre>\nec2-list.yaml<\/code> workflow file in your repository and copy the following workflow.<\/p>\nname: List EC2 Instances\n\non:\n push:\n branches:\n - main\n\npermissions:\n id-token: write\n contents: read\n\njobs:\n list-ec2:\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout repository\n uses: actions\/checkout@v3\n\n - name: Configure AWS credentials using OIDC\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: ${{ secrets.AWS_OIDC_ROLE }}\n aws-region: us-west-2\n\n - name: List EC2 Instances\n run: |\n aws ec2 describe-instances \\\n --query \"Reservations[*].Instances[*].InstanceId\" \\\n --output table\n<\/code><\/pre>\n![\"\"](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-24.png\")
<\/figure>\nStep 5: Enabling GitHub Actions Access to Amazon EKS via OIDC<\/h3>\n
aws eks create-access-entry \\\n --cluster-name <your-cluster-name> \\\n --principal-arn <your-role-arn-here>\n --kubernetes-groups github-runners \\\n --type STANDARD \\\n --username github-actions-oidc<\/code><\/pre>\naws eks list-access-policies --output table<\/code><\/pre>\n aws eks associate-access-policy \\\n --cluster-name <your-cluster-name> \\\n --principal-arn <your-role-arn-here> \\\n --policy-arn arn:aws:eks::aws:cluster-access-policy\/AmazonEKSViewPolicy \\\n --access-scope type=cluster<\/code><\/pre>\nStep 6: Test The EKS Workflow<\/h2>\n
\n
![\"\"](\"https:\/\/cdn.hashnode.com\/res\/hashnode\/image\/upload\/v1745351829696\/da7a47f6-ef88-42fe-9dd2-9722d9b52750.png\")
<\/figure>\nworkflow_dispatch<\/code> trigger to deploy the workflow manually from the GitHub UI.<\/p>\nname: Deploy NGINX to EKS\n\non:\n workflow_dispatch:\n\npermissions:\n id-token: write\n contents: read\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout repository\n uses: actions\/checkout@v3\n\n - name: Configure AWS credentials using OIDC\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: ${{ secrets.AWS_OIDC_ROLE }}\n aws-region: us-west-2\n\n - name: Set up kubeconfig\n run: |\n aws eks update-kubeconfig --region us-west-2 --name eks-spot-cluster-bibin\n\n - name: Deploy NGINX to EKS\n run: |\n kubectl create deployment nginx --image=nginx --port=80 --dry-run=client -o yaml | kubectl apply -f -<\/code><\/pre>\n![\"GitHub](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/image-44.png\")
<\/figure>\nOpenID Connect Workflow<\/h2>\n
![\"GitHub](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/05\/actions-oidc-aws-1.png\")
<\/figure>\n\n
aws-actions\/configure-aws-credentials<\/code> action makes a request to GitHub’s OIDC provider for a JWT token.<\/li>\naws-actions\/configure-aws-credentials<\/code> action exposes these credentials as environment variables (e.g., AWS_ACCESS_KEY_ID<\/code>, AWS_SECRET_ACCESS_KEY<\/code>, AWS_SESSION_TOKEN<\/code>)<\/li>\nConfiguring OIDC for AWS with Self-Hosted GitHub Enterprise Server (GHES)<\/h2>\n
\n
https:\/\/<GHES_HOSTNAME>\/_services\/token<\/code><\/li>\nConclusion<\/h2>\n
\n