No post body was provided.
Untitled topic
1–7 of 7 posts
Re: undefined
#2In case somebody looks for a quick summary of "this" in "...and then this happened". There's no single "this". It was many steps and eventually AWS rolled out a fix a month later.
Re: undefined
#3In case somebody looks for a quick summary of "this" in "...and then this happened". There's no single "this". It was many steps and eventually AWS rolled out a fix a month later.
(One of the authors here) That's absolutely true. Not easy to summarize the hard work involved on all sides in a short title: finding an issue, communicating it to the security team and then resolving the issue.
A slightly longer version of 'this': AWS really swiftly acknowledged the issue and fixed it in the latest version of AWS CDK. In case you use the `eks.Cluster` component of the AWS CDK, and you use AWS CDK If you want to learn more about what the issue was exactly, I'd be happy if you give the blog post a read :)
Re: undefined
#4In case somebody looks for a quick summary of "this" in "...and then this happened". There's no single "this". It was many steps and eventually AWS rolled out a fix a month later.
(One of the authors here) That's absolutely true. Not easy to summarize the hard work involved on all sides in a short title: finding an issue, communicating it to the security team and then resolving the issue. A slightly longer version of 'this': AWS really swiftly acknowledged the issue and fixed it in the latest version of AWS CDK. In case you use the `eks.Cluster` component of the AWS CDK, and you use AWS CDK If…
You are going for click bait and the post you are replying to is reacting to that to save those of us who wont click through.
Re: undefined
#5clickbait.
Re: undefined
#6Earlier quoted context omitted.
(One of the authors here) That's absolutely true. Not easy to summarize the hard work involved on all sides in a short title: finding an issue, communicating it to the security team and then resolving the issue. A slightly longer version of 'this': AWS really swiftly acknowledged the issue and fixed it in the latest version of AWS CDK. In case you use the `eks.Cluster` component of the AWS CDK, and you use AWS CDK If…
You are going for click bait and the post you are replying to is reacting to that to save those of us who wont click through.
Totally agree, I was expecting AWS to have done something shocking in response to their finding. No need to undermine their own work with a clickbait title.
Re: undefined
#7The clickbait title is undermines the seriousness of this issue.
In case it wasn’t explained clearly in this blog post, the IAM role that creates an EKS cluster becomes sort of the “principal” of the cluster and has default system:masters privileges. These permissions are typically handled by the aws-auth configmap, but for this initial creator of the cluster, as the article explains, is not added to this map but retains system:master permissions anyway. So making this CDK role tied to this invisible permission is quite a big deal.
As a best practice in my cluster creation automation I typically add the role that created the cluster to the aws-auth configmap right away. However, due to this bug, any clusters created with the flaw described in the article will pretty much need to be recreated from scratch, as I am not aware of a way to remove this invisible permission from EKS. It’s one of the “features” of EKS I’ve always hated the most.
I can’t believe no one noticed this in nearly 3 years.