-
Notifications
You must be signed in to change notification settings - Fork 294
[v0.16.0] Creating a switch to disable ICMP Ping instead of the default allow 0.0.0/0 #1854
[v0.16.0] Creating a switch to disable ICMP Ping instead of the default allow 0.0.0/0 #1854
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hey @dominicgunn, can i get a few pointers when you have time. Not sure what needs modifying to fix the build errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a comment for you @HarryStericker
{ | ||
"CidrIp": "0.0.0.0/0", | ||
"FromPort": -1, | ||
"IpProtocol": "icmp", | ||
"ToPort": -1 | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this might be your issue. Now that this is optional ({{ if .... }}
) the block above is going to leave a trailing ,
if this is disabled, like this.
....
"ToPort": 22
},
]
We can't have that trailing ,
if openICMP
is disabled.
This will also need changes to the go code, so we can add OpenICMP as a struct. Do a search for cloudFormationStreaming
.
Codecov Report
@@ Coverage Diff @@
## master #1854 +/- ##
=======================================
Coverage 24.40% 24.40%
=======================================
Files 98 98
Lines 5117 5117
=======================================
Hits 1249 1249
Misses 3728 3728
Partials 140 140
Continue to review full report at Codecov.
|
/lgtm |
Currently kube-aws includes a rule in its security group to allow ping from all traffic (0.0.0.0/0). Unless this is necessary for a reason I have not foreseen, it is an inherent security risk, violates CIS compliance, and is probably superfluous if SG's are managed appropriately.
Therefore, I have created a switch in cluster.yaml to allow removal of this rule. I have left it enabled by default but am conscious that anyone upgrading needs to ensure this is in their cluster.yaml, so am happy to adjust the logic so that there's no impact unless you explicitly ask for it to be disabled.
I don't think I've missed any other spots where this rule is used.