Support for SecurityGroupPolicy CRD

[sc250024]

I have issues

I'm submitting a...

• bug report
• feature request
• support request - read the FAQ first!
• kudos, thank you, warm fuzzy

Description

On September 9th, AWS published this article (https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods/) announcing support for the new SecurityGroupPolicy CRD, which allows a user to attach security groups directly to Pods.

There are some requirements that need to be added as part of this (original here: https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html):

• Your Amazon EKS cluster must be running Kubernetes version 1.17 and Amazon EKS platform version eks.3 or later. You can't use security groups for pods on Kubernetes clusters that you deployed to Amazon EC2.

• Security groups for pods are supported by most Nitro-based Amazon EC2 instance families, including the m5, c5, r5, p3, m6g, cg6, and r6g instance families. The t3 instance family is not supported. For a complete list of supported instances, see Amazon EC2 supported instances and branch network interfaces. Your nodes must be one of the supported instance types.

It also involves an additional IAM attachment:

Add the AmazonEKSVPCResourceController managed policy to the cluster role that is associated with your Amazon EKS cluster. The policy allows the role to manage network interfaces, their private IP addresses, and their attachment and detachment to and from instances. The following command adds the policy to a cluster role named .

aws iam attach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController \
    --role-name <eksClusterRole>

Clarification

My question is, given #635, I'm hesitant to start adding new features now.

What have we decided on this?

[barryib]

This module will now AmazonEKSVPCResourceController add #1011

For the rest, I think that @max-rocket-internet proposition is the way to go #1021 (comment)

[barryib]

Since the module now add the AmazonEKSVPCResourceController policy, you can now use the aws-vpc-cni chart to set ENABLE_POD_ENI=true as defined in docs.

From there I think you're ready to start defining your SecurityGroupPolicy CRD with helm, kubectl or any of your favorite tool. Or you can try https://registry.terraform.io/providers/hashicorp/kubernetes-alpha/latest/docs.

@sc250024 Is this sounds good to you ?

[sc250024]

Since the module now add the AmazonEKSVPCResourceController policy, you can now use the aws-vpc-cni chart to set ENABLE_POD_ENI=true as defined in docs.

From there I think you're ready to start defining your SecurityGroupPolicy CRD with helm, kubectl or any of your favorite tool. Or you can try https://registry.terraform.io/providers/hashicorp/kubernetes-alpha/latest/docs.

@sc250024 Is this sounds good to you ?

Yes that works. Thank you!

[barryib]

For the records, we tried to use kubernetes-alpha, but we found that it has a huge limitation: It doesn't work well with not yet known ressources. That means, you can't create, by example, a security group and create a SecurityGroupPolicy CRD during the same plan/apply. See hashicorp/terraform-provider-kubernetes-alpha#123 for more info.

As workaround, we use helm with the terraform helm provider to managed the SecurityGroupPolicy CRD. Actually, we use https://github.com/helm/charts/tree/master/incubator/raw.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.