We reported a security issue in AWS CDK’s eks.Cluster component | Hacker News Reader

We reported a security issue in AWS CDK’s eks.Cluster component

garden.io

62 pointsOrzelius9 comments

Disclosure: Work for AWS in a non-related capacity.

I understand the desire (and need) to post a postmortem as a part of responsible disclosure (which the authors of the article did). But I wish that these sorts of write ups made it clear that the security issue was fixed in the headline.

Just saying 'We reported something' creates a lot of FUD as end users of a service read the headline and lose their shit thinking that their infrastructure is still impacted. Even though this issue has already been fixed.

I wish Amazon AWS would make use of CVEs. This way we users can all see and track security vulnerabilities in real-time, in a central and organized place, instead of relying on individual word of mouth.

It's not a principle on HN that titles should tell the whole story, such that people can get the entire gist just by skimming the titles.

What kind of non-admin entity has permissions to assume any role with `sts:AssumeRole` on `*`?

One of the authors here - while it is a best practice to restrict the roles any identity can assume, following the concept of defense in depth it is also good to use trust policies on the roles to be extra safe.

I'm not sure if I'm reading this correctly. The statements below are my understanding, but it'd be great if you can confirm to provide more color.

The pre-patch setup would just make the implicit trust policy explicit, meaning any user or role in the account with `sts:AssumeRole` on `*` could assume the role (which is still the default when not trust policy is specified).

This change improves the posture by adding a trust policy to the role that prevents any roles other than those two listed from assuming the role. So this is purely a defense in depth measure, and not really a security vulnerability (unless we say the default, implicit trust policy is a security vulnerability itself :P).

Another default policy to consider is any Lambda function role. They never specify which Lambda can assume them (because that would create a cyclical dependency). That means anyone with permissions to create a Lambda will be able to technically assume this role.

Just like you, I'm not arguing the defense in depth part. Always a good idea to put fine-grained permissions where possible. But I also find the "vulnerability" part a tiny bit overstated.

That's a bit different and (like ec2 and other services) governed by IAM:Passrole. Whoever creates the lambda or ec2 needs to be allowed to assign that role. Otherwise it would allow privilege escalation.

This special creation role has always puzzled me a bit. Why does there need to be a special role with unrevokeable root privileges? I understand that it's useful, but why can't I at some point revoke its privileges when I'm done bootstrapping the cluster? If I do that in such a way that I need AWS support to help me get into a cluster I've locked myself out of, so be it.

Reply on news.ycombinator.com