Tags are set to Nil when creating network interfaces in https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/provider/branch/trunk/trunk.go#L191

[alexmnyc]

Tags are set to Nil when creating network interfaces in https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/provider/branch/trunk/trunk.go#L191

This does not work for any enterprise deployments where IAM deployer policies revolve around tag conditions for resources.

Please provide a mechanism similar to AWS ENI plugin https://github.com/aws/amazon-vpc-cni-k8s#additional_eni_tags-v160 to tag resource with custom tags so that governance and ownership can easily be defined.

[M00nF1sh]

@alexmnyc
For your use case,
Is a fixed set of tags be sufficient? such as clusterName & nodeARN.
Or it's required to allow you customize the set of tags.

[alexmnyc]

It's required that all resources created should come with a static set of tags i.e. AppId = X, AppName = Y. IAM policies are written with such resource constraints to ensure application ownership is isolated in a multi-tennant account and the owner can only create/update/delete resources with the same AppId/AppName tags as the deployer IAM role Principal AppId/AppName tags. Each deployer role is AppId/AppName specific

Just to note. A two step operation 1. Create Eni, 2. Tag Eni — will fail as 1 should come with tags included during Create

[M00nF1sh]

@alexmnyc
So if i understand this correctly, you want to be able to customize the static set of tags right.

we are going to support customize vpc resource controller's behavior via a Configmap Cx can tune. We'll bring this to our PM to see whether this could be part of the configmap.

[alexmnyc]

We are an AWS Enterprise client. It would be nice if different projects at AWS followed a similar pattern. Please review eks cni plug-in implementation. It seems like the two should be working and configured in tandem in a similar fashion. ConfigMap is fine but that's not what the cni plug-in project uses they use the env var, we patch a deployment with it. Ideally the format should be the same but we can workaround it

[haouc]

@alexmnyc sorry for missing update on this. As Yang mentioned, we are looking at options using CM for both addons. Using ENVs has brought many issues to our users and engineers. We would like to explore better options to avoid adding more ENVs.
I would keep this issue open for now unless you think this is no longer an issue. Thanks.