[HELP] Someone read the logs before asking — this is a known issue and the answer isn't here.

Opening thread commentary.

My bad, just checked the docs and figured it out. Thanks for pointing that out.

The error 403: Insufficient Permissions on your worker pod isn't about RBAC — that would be a 401 or a different error code entirely. It's an IAM condition mismatch.

Check two things first, in this order:

1. Node role vs. Pod identity. If you're using IAM Roles for Service Accounts (IRSA) on EKS/GKE Autopilot, your pod uses the OIDC-federated identity of its Kubernetes service account — not the node's instance profile. Verify that eks.amazonaws.com/role-arn is actually in the Pod spec and that the trust policy on the IAM role allows your cluster's OIDC issuer to assume it.

2. VPC Endpoint policies. If this traffic goes through a VPC endpoint for S3 or DynamoDB, there's an additional layer of authorization: the endpoint policy itself can override what the pod has permission to do

If you could attach whatever log snippet you think is relevant, I might be able to tell you which line of the stack trace matches the known issue from Issue #7421 on GitHub. Otherwise — and this is a genuine suggestion, by the way — just search the forum for "K

Thanks, already checked the logs but still stuck on step 3. Is there any other fix

I am going to try and be as exhaustive as possible because I have seen people get bitten by this edge case before, and it is genuinely one of those issues that looks trivial until it isn't. The logs you are seeing — the ERR_CONNECTION_RESET firing on ~14% of requests at the load balancer layer while the application server itself reports 200s — indicates a specific TCP state machine mismatch between your ingress proxy and your upstream service, and there is an extremely high probability that this is being triggered by one of three things, in descending order of likelihood given what you've described.

First possibility: the keepalive timeout on your Nginx (or whatever ingress you are running) is set higher than the keepalive idle timeout on the upstream application server. This creates a race condition where the load balancer attempts to reuse a connection that the backend has already closed. The proxy sends data into what it believes is an active pipe, the kernel receives RST because the four-tuple no longer exists in the backend's connection table, and you get your error. Fix: set keepalive_timeout on Nginx higher than or equal to your upstream timeout — usually 60s minimum for web traffic with long tails, but 120s is safer if your app has slow connections.

Second possibility: the backend is silently dropping packets when it exceeds a per-connection max size limit and you are not seeing this in your logs because the request never reaches the application layer — it gets reassembled at the socket buffer level and dropped there by a security module (iptables rate limiting, Fail2Ban, or a WAF policy). Check dmesg for any connection drop notifications. If that's what's happening, you need to tune your tcp_max_syn_backlog up and check whether your firewall has an active state table limit being hit under load.

Third possibility:

True, I checked and found it in line 412 of the build log before posting

I am going to assume for the sake of brevity that you have actually looked at anything before posting this, because I don't have time today to teach someone how to read a stack trace.

This is issue #4721 — it was tagged as known-fix in April and