3 Tier Application on EKS: Eliminating AWS Keys
Learn how to secure Amazon EKS and GitHub Actions deployments using OIDC and Kubernetes Access Entries.
Stock photo for illustration only, not from the actual event
- Remove static AWS Access Keys from GitHub repository settings for better security.
- Replace permanent keys with short-lived GitHub OIDC tokens scoped to single jobs.
- Manage dual-layer authorization using AWS IAM and Kubernetes RBAC Access Entries.
Building a 3-tier application running on Amazon EKS and deploying it via a GitHub Actions pipeline triggered on every merge to the main branch often starts with storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY inside repository settings. While functional, this approach poses significant security risks if keys leak, because standard access keys do not expire until manually revoked.
A superior alternative is OpenID Connect (OIDC), which replaces static credentials with tokens living only for the duration of a single job. No secrets are stored anywhere, and trust relies entirely on token claims rather than a shared static string.
Transitioning from static keys to OIDC embodies modern Zero Trust security principles, limiting the blast radius if a CI/CD pipeline is ever compromised. Short-lived tokens eliminate the overhead of manual key rotation and completely prevent accidental credential exposure within version control systems.
The setup begins by creating an OpenID Connect provider in AWS IAM pointing to the GitHub Actions URL. AWS no longer requires manual certificate thumbprint management for this provider. Next, developers create an IAM Role and trust policy to specify which GitHub jobs can assume the role, utilizing environment-level controls in production for mandatory reviews.
Stock photo for illustration only, not from the actual event
A critical requirement is declaring the permissions block with permissions: id-token: write. Without this, GitHub will not mint the token, and the credentials step will fail with an unhelpful error message. Furthermore, declaring a permissions block resets all other permissions to none, meaning contents: read must be explicitly added if the job checks out code.
Even after successfully authenticating with AWS IAM, pipelines frequently fail at the kubectl step with an Unauthorized error. This happens because EKS operates on two distinct authorization layers: IAM determines whether you can reach the cluster API endpoint, while Kubernetes RBAC dictates what actions you are permitted to perform once inside.
To resolve this, the new IAM role must be explicitly mapped into the cluster. If your cluster relies on an older ConfigMap setup, authentication modes must be updated to support the EKS Access Entries API or properly configured via the aws-auth ConfigMap in the kube-system namespace, binding deployment roles strictly to scoped Kubernetes roles like AmazonEKSEditPolicy.
"error: You must be logged in to the server (Unauthorized)"
Mayank Thakur
Following this migration, the repository contains zero static AWS secrets. The credentials held by a job remain valid solely for that execution, tightly scoped to a single namespace and branch, drastically minimizing potential security exposure.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment