Application Networking — Journey through VPC LATTICE! Part 01

Hello everyone, how are you doing? I’m here again to share with you the best way to start working with AWS VPC Lattice. Enjoy!

Objectives of this post:

• Set up a VPC lattice: Install Networking Gateway on EKS;

Step 0

Before we start this project, you need to have an EKS cluster running and access to kubectl, eksctl and Helm.

Installation Guide: https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html

— You need to have a minimal knowledge of networking and VPC. This story is about a complex service, and I won’t be covering the basics. —

Step 1 — Enable the Gateway API communication

You need to make sure that Pods communicating with VPC Lattice to allow traffic from the VPC Lattice managed prefix lists. To do this, you need to go:

1° AWS VPC DASHBOARD
2° Managed prefix list
3° Search fot vpc-lattice
4°Get IPV4 Range address.

VPC-LATTICE-GET-PREFIX-LIST

After that, you need to go in your EKS security group and make sure that IPV4-Range is able to communicate with your cluster.

EKS-CLUSTER-SG

Sure!

Step 2 — IAM Policy and Service Account

Now, you need to create an IAM role and SA for your gateway. First, retrive this json example for your policy:

https://raw.githubusercontent.com/aws/aws-application-networking-k8s/main/files/controller-installation/recommended-inline-policy.json

Create an IAM POLICY with this JSON. Usually, the peoples used to “ VPCLatticeControllerIAMPolicy”

Great. Now, here we go to create an IAM ROLE. We have 2 options: IRSA and Pod Identities ( recommended by AWS), lets do the second option.

First, you need to install eks-pod-identity-agent addon. You can do this in console or awscli.

AWSCLI:

aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1

Console:

Select eks-pod-identity-agent addon, and be happy. =)

After that, create a Service Account.

apiVersion: v1
kind: ServiceAccount
metadata:
    name: gateway-api-controller
    namespace: aws-application-networking-system

And a trust policy for IAM Role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

Now, you can create the role:

aws iam create-role --role-name VPCLatticeControllerIAMRole --assume-role-policy-document file://trust-relationship.json --description "IAM Role for AWS Gateway API Controller for VPC Lattice"
aws iam attach-role-policy --role-name VPCLatticeControllerIAMRole --policy-arn=$VPCLatticeControllerIAMPolicyArn
export VPCLatticeControllerIAMRoleArn=$(aws iam list-roles --query 'Roles[?RoleName==`VPCLatticeControllerIAMRole`].Arn' --output text)

Attention with your policy name, maybe you need to change these commands.

Our last configuration here, its just to create an association between the SA and IAM ROLE

aws eks create-pod-identity-association --cluster-name $CLUSTER_NAME --role-arn $VPCLatticeControllerIAMRoleArn --namespace aws-application-networking-system --service-account gateway-api-controller

Great!

Step 3 — Deploy Lattice Controller

This step is simple and complicated at the same time. You need to have attention now.

Usually, EC2 instance are working with IMDSV2 Metadata REQUIRED, because the AWS Best Practices. This way solves a security challenge for cloud users by providing access to temporary and frequently-rotated credentials, and by removing the need to hardcode or distribute sensitive credentials to instances manually or programmatically ( by aws)

OK, but, what is the problem here? Its simple. Usually, when you deploy the controller, we have 2 containers inside the pod, they’re called: kube-rbac-proxy and manager.

kube-rbac-proxy is a small HTTP proxy for a single upstream.
Manager: Its the controller.

The Manager container get some informations from the EC2 (NODE) metadata , like: AWS region, AWS Account and AWS VPC. but…f your nodes are using IMDSv2, you need to authenticate the request.. Can you guess now? …..

Yes. the manager application don’t have a necessary configuration to get this information.

If you try, you’ll recive an error like this:

init config failed: vpcId is not specified: EC2MetadataError: failed to make EC2Metadata request\n\n\tstatus code: 401, request id

Official documentation describe a little bit about this. But I’m here to help you! =)

You have 2 options to resolve this.

1° Set the required ENVS in your Helm or YAML that you use to deploy

clusterName
awsRegion
awsAccountId
clusterVpcId

Read more here

2° Change your EC2 Instance-pool from V2 Only to V1 and V2. I can’t begin to imagine what you need to use this, but, its an option.

Still about the second option, you have two way.

First: Modify your Launch Template in the Metadata options

Token-Optional

Second: Modify your EC2:

And, for the best option you can use kubectl or Helm to deploy the controller.

Here, we’re going to setup the controller with HELM.

# login to ECR
aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws
# Run helm with either install or upgrade
helm install gateway-api-controller \
    oci://public.ecr.aws/aws-application-networking-k8s/aws-gateway-controller-chart \
    --version=v1.1.0 \
    --set=serviceAccount.create=false \
    --namespace aws-application-networking-system \
    --set=log.level=info # use "debug" for debug level logs

Enjoy it!