Please vote on this issue by adding a đź‘Ť reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
My colleagues and I recently encountered container network issues in an ECS cluster with AMIs baked from hardened Amazon Linux 2 images released by CIS in August and September—ami-06d59d546f413a803 and ami-080cfaeb213b9f981, respectively. Ultimately, we discovered that iptables was masked by default in these AMIs in contrast to previous Amazon Linux 2 images from the same vendor. As a result, iptables rules added by Docker/ECS as well as one we input manually had no effect on network access, preventing all outbound connectivity from the containers hosted on ECS cluster instances launched from these AMIs.
Since it appears that many distributions may deprecate iptables in favor of nftables in the future, we conducted some additional research but found little content on this subject and reached out to AWS Support for guidance. They pointed us to a Docker issue on this subject [1], but since there we couldn't find anything specific to ECS, we've decided to raise this issue to solicit feedback from the AWS and other ECS users. Feel free to share any insight into where this might fit into the AWS' ECS/EKS roadmap, lessons from similar experiences, or use cases that might benefit from native nftables support.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
Are you currently working around this issue?
To correct this issue we crafted two basic workarounds. The first merely replaces nftables with iptables, either by baking these changes into the AMI or by running the required commands at boot via instance user data. Meanwhile, our second strategy keeps iptables masked but installs iptables-nft and maps iptables commands to the relevant iptables-nft binary, so that iptables rules added at boot or applied by ECS are translated to the nftables ruleset.
Community Note
Tell us about your request My colleagues and I recently encountered container network issues in an ECS cluster with AMIs baked from hardened Amazon Linux 2 images released by CIS in August and September—ami-06d59d546f413a803 and ami-080cfaeb213b9f981, respectively. Ultimately, we discovered that iptables was masked by default in these AMIs in contrast to previous Amazon Linux 2 images from the same vendor. As a result, iptables rules added by Docker/ECS as well as one we input manually had no effect on network access, preventing all outbound connectivity from the containers hosted on ECS cluster instances launched from these AMIs.
Since it appears that many distributions may deprecate iptables in favor of nftables in the future, we conducted some additional research but found little content on this subject and reached out to AWS Support for guidance. They pointed us to a Docker issue on this subject [1], but since there we couldn't find anything specific to ECS, we've decided to raise this issue to solicit feedback from the AWS and other ECS users. Feel free to share any insight into where this might fit into the AWS' ECS/EKS roadmap, lessons from similar experiences, or use cases that might benefit from native nftables support.
[1] Native support for nftables #1472: https://github.com/docker/for-linux/issues/1472
Which service(s) is this request for? ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
Are you currently working around this issue? To correct this issue we crafted two basic workarounds. The first merely replaces nftables with iptables, either by baking these changes into the AMI or by running the required commands at boot via instance user data. Meanwhile, our second strategy keeps iptables masked but installs iptables-nft and maps iptables commands to the relevant iptables-nft binary, so that iptables rules added at boot or applied by ECS are translated to the nftables ruleset.
Additional context None
Attachments None