Loading today’s stories
Build1 distinct publisher2 min readUpdated
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
Compiled by The EngineerSomething wrong?How this is made
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 [14]. 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 [3].
The author is direct about that being the step that broke and the step tutorials leave out [3]. The text supplied to us stops mid-command at the update-kubeconfig line [18], 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 [15]. Fold build and deploy into one role and that role holds seven actions across two services [19]; keep them apart, as the author does, and a compromised build stage has no route to the cluster at all [16].
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) [13], and EKS decides whether the resulting identity may touch a resource [3]. 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 [4], and its blast radius takes in forks and any third-party action the workflow pulls [6]. The OIDC exchange returns credentials that die with the job [7], a lifetime cut from unbounded to one run [20]. 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.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
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.
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.
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.
The author built a 3-tier application on Amazon EKS, deployed by a GitHub Actions pipeline that runs on every merge to main.
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.
An IAM access key does not expire; if it leaks it stays valid until someone notices and revokes it.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
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.
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 supplied material, so the pattern's real-world uptake cannot be sized from this cluster even though the individual instance is credible and dated.
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.
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.
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.
build
Partition, not consolidation: what a 43-minute Jenkins queue actually cost1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
build
Two Actions, One Loose Policy: The Bedrock Wildcards That Widen A Least-Privilege Grant1 distinct publisher
build
Send kills, not scores: the leaderboard fix that turns anti-cheat into a schema decision1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026