It seems that the current set of filters that used for DescribeSecurityGroups is inaccurate. The mentioned code passes the tests and works fine in general case, but can lead to wrong security group discovery in complex environments (when different controller-id values are used to separate kube-ingress-aws-controller instances).
To give you an example. There are two security groups with tags kubernetes:application=controller and kubernetes:application=controller-backup. With the current set of filters discovery will work like "contains" filter, but not an "exact" one.
In our example case, instance with controller-id controller will discover both security groups and might choose the wrong one. My personal observation is that the AWS API returns the list of found security groups in unsorted order. The behaviour is reproduced constantly.
It seems that the current set of filters that used for
DescribeSecurityGroups
is inaccurate. The mentioned code passes the tests and works fine in general case, but can lead to wrong security group discovery in complex environments (when differentcontroller-id
values are used to separatekube-ingress-aws-controller
instances).To give you an example. There are two security groups with tags
kubernetes:application=controller
andkubernetes:application=controller-backup
. With the current set of filters discovery will work like "contains" filter, but not an "exact" one.https://github.com/zalando-incubator/kube-ingress-aws-controller/blob/9f9d7c1bc57066f0350a0a684f92dd7d5f3ec45b/aws/ec2.go#L283-L310
In our example case, instance with controller-id
controller
will discover both security groups and might choose the wrong one. My personal observation is that the AWS API returns the list of found security groups in unsorted order. The behaviour is reproduced constantly.https://github.com/zalando-incubator/kube-ingress-aws-controller/blob/9f9d7c1bc57066f0350a0a684f92dd7d5f3ec45b/aws/ec2.go#L321
Here is an example snippet from AWS SDK for Go documentation with reference filters usage.