Open tazjin opened 8 years ago
I can see this being valuable. Should kube2iam also remove the rule when it's de-scheduled from a node? Might be important if/when #8 is implemented.
I'm not sure if it's possible to remove it reliably (what if kube2iam crashes / gets killed for some reason?). I think in terms of worst-case scenarios failing credential lookups may be better than privilege escalations.
related commit of how Amazon ECS handles it: https://github.com/aws/amazon-ecs-init/commit/04d5735d8b9b5a81e55ae87971b196bbc5e2944c
although that might be only done during instance initialization, and would not solve the case corrupted routing tables.
@tazjin have you put any work into this? If not, I may tackle it over the next few days. As far as removing the rule, I'm thinking we could implement it as a PreStop hook.
@mgoodness Nope, not yet. I'm currently tracking issue #8 as well because it may be very relevant to let the masters deal with running kube2iam
such that the nodes don't need to have the sts:AssumeRole
capability.
When kube2iam is configured to set up the iptables rule I think it should also monitor the rule's presence somehow. I for one am afraid of some process resetting the rule and thus allowing pods some dangerous privilege escalations.
Thoughts on this? If people think it's a good idea I may be able to spend some time on implementing it.