We reported a security issue in AWS CDK’s eks.Cluster component
1–10 of 12 posts
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#2What kind of non-admin entity has permissions to assume any role with `sts:AssumeRole` on `*`?
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#3What 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.
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#4What kind of non-admin entity has permissions to assume any role with `sts:AssumeRole` on `*`?
[dead]
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#5What 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).
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#6Disclosure: 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.
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#7Disclosure: 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…
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.
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#8Disclosure: 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…
[deleted]
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#9Earlier quoted context omitted.
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…
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.
Re: We reported a security issue in AWS CDK’s eks.Cluster component
#10Disclosure: 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…
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.