Build Not yet confirmed elsewhere 1 publisher2 min readPublished Aug 22, 2026, 10:21 AM PDT

Dropping long-lived AWS keys is half an EKS migration; the cluster still gets a vote

A clean STS exchange proves only that IAM let the job in. EKS authorizes separately, and that is the half of the migration most walkthroughs skip.

The Engineer · Build desk

How we use AI Send a correction

What happened

The pipeline's first version kept AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in repository settings, and the author says they worked.
The replacement: GitHub mints a per-job token, STS checks its signature against a registered provider and its claims against the role's trust policy.
The workflow side is small: id-token write permission, contents read, and configure-aws-credentials v4 with a role ARN, a session name and a region.
AWS now verifies and rotates the provider certificate itself, so the old thumbprint value only matters for tooling that still insists on one.

Why it matters

constraint A successful credentials step can no longer serve as the deploy gate, because the permission that decides the outcome sits outside anything an IAM policy review reads.
exposure A sub pattern one character wider than intended promotes everyone who can open a pull request into a deployer, and IAM will consider that correct.
cost Standing keys look cheap because their maintenance bill is deferred: rotation cost grows with every repository holding the key, so it gets paid only after a leak.
decision One role for build and deploy becomes hard to defend once you have to argue why a build step should be able to reach the cluster at all.

Two systems get a vote here, and only one of them leaves a trace where you are looking. The deploy role in this setup carries a single IAM action, eks:DescribeCluster against one cluster ARN ^[15]. That is enough to fetch an endpoint and write a kubeconfig. So the run collects its temporary credentials, writes the file, and then the cluster forms an opinion of its own, because EKS layers authorization above IAM ^[1].

The author is direct about that being the step that broke and the step tutorials leave out ^[1]. The text supplied to us stops mid-command at the update-kubeconfig line ^[3], so the cluster-side grant itself is not on the page, and I am not going to invent one. What travels anyway is the shape of the problem: an identity that authenticates perfectly can still be a stranger to the thing it is trying to change.

The permission arithmetic is worth copying. A job that also pushes images needs six ECR actions ^[16]. Fold build and deploy into one role and that role holds seven actions across two services ^[18]; keep them apart, as the author does, and a compromised build stage has no route to the cluster at all ^[17].

There are three enforcement points, and each is blind to the other two. IAM decides which jobs may assume the role, GitHub decides who may trigger those jobs (the author uses environments with a required reviewer for production) ^[14], and EKS decides whether the resulting identity may touch a resource ^[1]. A migration that only touches the first will pass every check the first is capable of performing.

The credential story does improve. An access key never expires and stays valid after a leak until somebody revokes it ^[6], and its blast radius takes in forks and any third-party action the workflow pulls ^[7]. The OIDC exchange returns credentials that die with the job ^[8], a lifetime cut from unbounded to one run ^[19]. What replaces the key is not nothing, though: it is a piece of cluster state that has to exist, that no IAM policy review will miss, and that aws sts get-caller-identity will happily not mention.

Which sets the acceptance test. The only run that proves this migration landed is one where the deploy role, from CI, asks the cluster for something and gets an answer back. Anything short of that tests AWS authentication, which was never the part in doubt.

What to watch

Whether the rest of the walkthrough shows how the cluster-side grant for the deploy role is created, and whether that step is automated or done once by hand.
Whether the two-role split holds up once a build stage needs to read cluster state, for smoke tests or migrations, and quietly acquires cluster access.
Any change to the sub claim patterns GitHub emits, which would either widen or break trust policies written against the current form.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence46
Adoption16
Hype gap+9
Incentives27
Confidence48

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The author states that getting past IAM is only half the job because EKS has its own authorization layer on top of IAM, and that this is the part that broke for him and that most tutorials skip.
ReportedSupported2 sources— create a free account to open them View cited source
[2]
The workflow sets permissions id-token: write and contents: read, and uses aws-actions/configure-aws-credentials@v4 with a role-to-assume ARN, a role-session-name of gha-deploy-${{ github.run_id }} and aws-region ap-south-1.
ReportedSupported2 sources— create a free account to open them View cited source
[3]
The supplied source text ends mid-command at "aws eks upd" in the Update kubeconfig step, so no cluster-side authorization configuration is shown in the material provided.
ReportedSupported2 sources— create a free account to open them View cited source
[4]
The author built a 3-tier application on Amazon EKS, deployed by a GitHub Actions pipeline that runs on every merge to main.
ReportedSupportedView cited source
[5]
The first version of the pipeline had two secrets in the repository settings, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY; the author says they worked and were a bad idea.
ReportedSupportedView cited source
[6]
An IAM access key does not expire; if it leaks it stays valid until someone notices and revokes it.
ReportedSupportedView cited source
[7]
A fork or a compromised third-party action widens the blast radius of a key stored in repository settings.
ReportedSupportedView cited source
[8]
OIDC replaces the stored key with a token that lives for the length of a single job, and STS returns temporary credentials that expire when the job ends.
ReportedSupportedView cited source
[9]
The flow has four steps: GitHub Actions mints a short-lived JWT describing repo, branch and workflow; the workflow sends it to AWS STS; AWS checks the token signature against a registered identity provider and then the claims against the IAM role's trust policy; STS returns temporary credentials.
ReportedSupportedView cited source
[10]
The OIDC provider is created once per AWS account using aws iam create-open-id-connect-provider with url https://token.actions.githubusercontent.com and client-id-list sts.amazonaws.com.
ReportedSupportedView cited source
[11]
AWS no longer requires managing a certificate thumbprint for this provider and verifies and rotates the certificate itself; older guides use 6938fd4d98bab03faadb97b34396831e3780aea1 for tooling that still demands a value.
ReportedSupportedView cited source
[12]
The trust policy allows sts:AssumeRoleWithWebIdentity with a StringEquals condition on the aud claim equal to sts.amazonaws.com and a StringLike condition on the sub claim, shown as repo:my-org/my-repo:ref:refs/heads/main.
ReportedSupportedView cited source
[13]
The author says the sub condition is the only thing standing between "my main branch can deploy" and "anyone who opens a pull request against my repo can deploy".
ReportedSupportedView cited source
[14]
The author uses the environment form of the sub condition for production because GitHub environments allow a required reviewer; IAM enforces which jobs can assume the role and GitHub enforces who can trigger those jobs.
ReportedSupportedView cited source
[15]
The deploy role's permission policy grants a single action, eks:DescribeCluster, on one cluster ARN, described as enough to look up the cluster endpoint.
ReportedSupportedView cited source
[16]
If the same job also pushes images it needs six ECR actions: GetAuthorizationToken, BatchCheckLayerAvailability, PutImage, InitiateLayerUpload, UploadLayerPart and CompleteLayerUpload.
ReportedSupportedView cited source
[17]
The author prefers two separate roles, one for build and push and one for deploy, so that a compromised build step cannot touch the cluster.
ReportedSupportedView cited source
[18]
A single role covering both build-and-push and deploy would hold seven API actions across two AWS services, against one action for a deploy-only role.
DerivedSupported1 source— create a free account to open them
[19]
The migration reduces credential lifetime from unbounded to the duration of a single CI job.
DerivedSupported1 source— create a free account to open them
[20]
Rotating a stored key means updating every repository that uses it, so in practice nobody rotates it.
ReportedInsufficient2 sources— create a free account to open them View cited source

Sources

1 independent publisher whose own reporting we read for this story.

dev.to
1 article · August 22, 2026
3 Tier Application On EKS

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For a builder this is a near-complete recipe for keyless GitHub Actions to AWS: register the account-level OIDC provider (no thumbprint to babysit), write a trust policy whose StringEquals aud and StringLike sub conditions define exactly which job may assume the role, attach a permission policy that grants only eks:DescribeCluster on one cluster ARN, and wire the job with permissions id-token: write plus contents: read and aws-actions/configure-aws-credentials@v4. The two gotchas are stated plainly: omitting id-token: write yields a 'Could not assume role with OIDC' error that never names the cause, and declaring a permissions block resets everything to none. The recipe stops short at the important part — the source truncates before any cluster access-entry or RBAC mapping is shown, so a builder following it lands exactly where the author landed: authenticated to AWS and Unauthorized at kubectl.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence46: 0100
Concrete artifacts, one source, truncated at the decisive step
The mechanics are shown rather than asserted: the provider-creation command, a full trust policy with aud and sub conditions, a one-action permission policy, workflow YAML with the id-token permission, and verbatim error strings from a real failure. That is unusually checkable for a practitioner post. It is nonetheless a single publisher with no independent corroboration, two of its generalizations are unverifiable here, and the cluster-side authorization configuration — the half the headline is about — is cut off mid-command, so the remediation is described but never demonstrated.
Adoption16: 0100
One self-reported pipeline
Adoption evidence amounts to a single practitioner's own deployment — one 3-tier EKS application with a public repository link — plus the failures they hit while doing it. There is no telemetry, no organizational rollout, no third-party usage disclosure and no benchmark in the reporting, so the pattern's real-world uptake cannot be sized from this cluster even though the individual instance is credible and dated.
Hype gap+9: −100 understated0 aligned+100 overstated
Mostly hedged, two unsupported generalizations
The framing is unusually restrained for the genre — the thesis is that dropping static keys is only half the work, which the evidence supports, and the concrete steps match the artifacts shown. The mild overstatement comes from two unbacked universals ('in practice nobody rotates it' and that 'most tutorials skip' the EKS authorization layer) and from promising the cluster-side fix that the supplied text never delivers, which leaves the payoff slightly ahead of the demonstration.
Incentives27: 0100
Personal-portfolio promotion, no vendor stake visible
The visible incentive is reputational: an individual developer publishing on a community platform and linking their own GitHub project, which rewards a confident, tutorial-shaped narrative and discourages dwelling on unfinished parts. No sponsorship, vendor affiliation, commercial product, or paid placement appears anywhere in the supplied text, and the post recommends first-party AWS and GitHub primitives rather than anything it sells, so commercial distortion pressure is low.
Confidence48: 0100
Credible mechanics, thin sourcing
Confidence is limited by structure rather than plausibility: one publisher, one author, one project, and a body that terminates before the section the story hinges on. Within those limits the configuration-level claims are high-confidence because they are quoted artifacts, while the practice generalizations and the completeness of the remediation path are low-confidence.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

CI/CD Credential SecurityFollow
Kubernetes Cluster Access ControlFollow
Least-Privilege IAM Role DesignFollow
OIDC Workload Identity FederationFollow

Entities

Amazon EKS Follow
GitHub Actions Follow
AWS IAM Follow
AWS STS Follow
Amazon Elastic Container Registry Follow
aws-actions/configure-aws-credentialsFollow
OpenID Connect Follow
Kubernetes RBAC Follow
EKS Access EntriesFollow
kubectl Follow