Prevent unexpected privileges escalation #136
Conversation
|
Does anyone can take a look ? randomly @Gowiem |
|
Makes sense, thanks for this. I think we will change default too, but will check regression first |
Fine to me, but be careful with the default... ^^ A lot of people will have unexpected permissions not working anymore. It's a breaking change. |
|
/test all |
|
Both failures unrelated, I will fix in separate PR |
|
Any update on this PR ? I would love to see this released 🤗 |
|
/test test/readme |
|
@max-lobur this is odd. It seems like it's trying to revert it back to 2022 instead of using 2023. It should be using the latest build-harness which grabs rhe current year. |
|
Oh I see the issue. We just need to run the auto format again on this pr since this pr was submitted in 2022. Now its 2023 and the year should be 2023 in the readme. Please run |
|
/test all |
|
/test test/terratest |
|
/test test/terratest |
|
/test test/terratest |
|
/test test/terratest |
|
/test all |
|
Thank you @gillg for the contribution! |
what
The current variable
input_metadata_http_put_response_hop_limitcondition, prevent to protect users of this module, to be protected against privileges escalation.The first intent of IMDSv2 is to prevent containers beeing able to assume an EC2 instance profile. It's not a bad idea at all to prevent that. The good practice then is to use the module
cloudposse/eks-iam-role/awsto create a kubernetes service account mapped with IAM permissions throug an OIDC IdP.references