
## Introduction

### What Are We Building? 🔐

In this deep dive, we’ll secure traffic to an app on GKE using **mutual TLS (mTLS)** at the ingress layer with **GKE Gateway API**. We’ll use self-signed certs to demo client certificate validation—similar to how financial APIs and zero-trust platforms validate service-to-service identity.

### Why This Matters

mTLS is core to secure service meshes and external-facing APIs. Validating clients via TLS certs strengthens your perimeter, especially for sensitive workloads.

## Scenario Overview

- GKE Autopilot cluster (or standard)
- Gateway API enabled with managed Gateway controller
- One app (`httpbin`) behind the Gateway
- Server cert (`tls.crt`, `tls.key`) deployed via `Secret`
- Client cert (`client.crt`) validated against a CA bundle (`ca.crt`)
- All certs are self-signed for demo, in real-world you'd use cert-manager or ACM

## Architecture

![mTLS Gateway](/images/mtls-gke.png)

- Gateway only accepts connections where client cert is signed by known CA
- Ingress TLS termination happens at Gateway
- Backend is HTTP (no mTLS between Gateway and app in this example)

## Prereqs

- GCP project with billing enabled
- `gcloud`, `kubectl`, `openssl`
- Gateway API CRDs installed
- GKE cluster with Gateway controller enabled

## Step-by-Step Setup

### Step 1: Create the Cluster

```bash
gcloud container clusters create-auto mtls-demo \
  --region us-central1
```

### Enable Gateway API

```bash
gcloud container clusters update mtls-demo \
  --enable-gateway-api

# install CRDs if needed
kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v1.0.0"
```

### Generate TLS & CA Certs

```bash
mkdir certs && cd certs

# Create CA
openssl req -x509 -nodes -new -sha256 -days 3650 \
  -newkey rsa:2048 -subj "/CN=MyCA" \
  -keyout ca.key -out ca.crt

# Server cert
openssl req -new -newkey rsa:2048 -nodes -keyout server.key \
  -subj "/CN=httpbin.local" -out server.csr

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365

# Client cert
openssl req -new -newkey rsa:2048 -nodes -keyout client.key \
  -subj "/CN=test-client" -out client.csr

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out client.crt -days 365
```

### Deploy app & secrets

```bash
kubectl create ns httpbin

kubectl create deployment httpbin --image=kennethreitz/httpbin --port=80 -n httpbin
kubectl expose deployment httpbin --port=80 --target-port=80 -n httpbin

kubectl create secret tls server-cert \
  --cert=certs/server.crt --key=certs/server.key -n httpbin

kubectl create configmap ca-cert --from-file=ca.crt=certs/ca.crt -n httpbin
```

### Create Gateway & Routes

Gateway config (gateway.yaml)
```yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: httpbin-gw
  namespace: httpbin
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: server-cert
        options:
          networking.gke.io/client-verification: "require"
          networking.gke.io/trusted-ca: ca-cert
```

Route config (route.yaml)

```yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: httpbin
spec:
  parentRefs:
    - name: httpbin-gw
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: httpbin
          port: 80
```

Apply the configs:

```bash
kubectl apply -f gateway.yaml
kubectl apply -f route.yaml
```

### Test the setup

Get IP address of the Gateway:

```bash
kubectl get gateway -n httpbin
```

Let’s test with and without the client cert.

✅ Valid client

```bash
curl --cert certs/client.crt --key certs/client.key --cacert certs/ca.crt \
  https://<GATEWAY_IP>/get
```

❌ No client cert

```bash
curl --cacert certs/ca.crt https://<GATEWAY_IP>/get
```

Expected: 400 or 403 depending on GKE's enforcement.

### Automated Testing (Optional)

Create a script to automate the testing.

```bash
#!/bin/bash
URL=https://<GATEWAY_IP>/get
curl --silent --cert certs/client.crt --key certs/client.key --cacert certs/ca.crt $URL | grep "headers"
if [ $? -ne 0 ]; then echo "mTLS test failed"; exit 1; fi
echo "mTLS test passed"
```

## Key Takeaways

- GKE Gateway API supports native mTLS client validation via annotations
- Certs must be manually injected via Secret and ConfigMap
- Only valid clients (with signed certs) can connect

This pattern is extendable to service meshes, APIs, and zero-trust networking

## Code 

- [Blog Code](https://github.com/moanukar/mtls-gke)

## Conclusion

You now have a secure GKE Gateway that validates clients using mutual TLS. In the next part, we'll explore using cert-manager for automated cert issuance and chaining this setup with an internal-only backend.


In this blog, we configure mutual TLS (mTLS) using Gateway API on GKE, securing ingress traffic with client certificate validation.

Secure Gateways: Configuring Mutual TLS using Gateway API on GKE


## Introduction

DNS spoofing in Kubernetes remains a critical threat, enabling attackers to redirect traffic, intercept data, or disrupt services. This article explores how such attacks occur and outlines strategies to prevent them.

## K8s networking

In Kubernetes, pods communicate over a virtual bridge (commonly cbr0) that connects all pods on a node. The cbr0 can also handle ARP (Address Resolution Protocol) resolution. When an incoming packet arrives at cbr0, it can resolve the destination MAC address using ARP.

CoreDNS, running as a pod, handles DNS resolution for the cluster. Each pod's /etc/resolv.conf typically points to the ClusterIP of the CoreDNS service, often 10.96.0.10. Kube-proxy sets up iptables rules to route DNS requests to the appropriate CoreDNS pod.

In essence, this is how pods communicate with each other on the same node. It’s also how Docker works and is the default for K8s.

## Understanding How DNS Works Inside Kubernetes

Let’s break down how DNS requests flow in a Kubernetes cluster — especially how pods talk to CoreDNS.

Each pod in your cluster is set up to use CoreDNS (or kube-dns) as its default DNS server. CoreDNS itself runs as a pod, typically inside the kube-system namespace. You can have multiple CoreDNS pods for HA, but for simplicity, let’s assume one for now.

### How Does a Pod Know Where CoreDNS Lives?

When a pod is created, Kubernetes injects a /etc/resolv.conf file like this:

```bash
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```

That 10.96.0.10 is the ClusterIP of the kube-dns Service. It’s a stable VIP (virtual IP) used for all DNS requests inside the cluster. CoreDNS pods sit behind this service and receive DNS queries forwarded by kube-proxy using iptables DNAT rules.

### How the Flow Works

1. Your pod makes a DNS request (e.g. nslookup my-service)

2. It hits the VIP (10.96.0.10)

3. kube-proxy rewrites the packet (DNAT) to one of the actual CoreDNS pod IPs

4. CoreDNS checks:
    - Is this a cluster service/pod/etc? → resolve it locally
    - Else → forward to upstream DNS (e.g. Google DNS)

This behavior is defined by the pod’s dnsPolicy, which is set to ClusterFirst by default.

### From kubelet's DNS handling logic:

For a pod with DNSClusterFirst policy,
the cluster DNS server is the only nameserver configured.
CoreDNS will forward queries to upstream nameservers
if it can’t resolve them locally.

### 🧩 Key Point

A pod doesn’t talk to CoreDNS directly by IP — it talks to a Service VIP that’s transparently routed to a pod. This abstraction makes DNS scalable and fault-tolerant, but also opens the door for network-layer attacks like DNS spoofing if a pod has raw socket access.

## The Attack Vector: ARP Spoofing via NET_RAW

By default, Kubernetes grants pods the NET_RAW capability, allowing them to craft raw packets, including ARP messages. An attacker can exploit this to perform ARP spoofing, tricking the network into sending DNS requests to a malicious pod instead of the legitimate CoreDNS pod.

### Steps to Exploit

1. Identify CoreDNS Pod IP: Send a DNS request and observe the source IP of the response to determine the CoreDNS pod's IP.

2. Determine Bridge IP and MAC: Use tools like scapy to send packets with TTL=1 to an external IP, capturing the bridge's IP and MAC address.

3. Send Fake ARP Replies: Continuously send ARP replies to the bridge, associating the CoreDNS IP with the attacker's MAC address.

4. Intercept DNS Requests: Run a DNS proxy in the malicious pod to handle intercepted DNS requests, forwarding them to the real CoreDNS pod or spoofing responses as desired.

This method allows the attacker to intercept and manipulate DNS traffic, potentially redirecting services to malicious endpoints.

## Mitigation Strategies

1. Drop NET_RAW Capability

Modify pod security contexts to drop the NET_RAW capability, preventing pods from crafting raw packets.

```yaml
securityContext:
  capabilities:
    drop:
      - NET_RAW
```

1. Implement Network Policies
Use Kubernetes NetworkPolicies to restrict pod communication, ensuring only authorized pods can communicate with CoreDNS.

1. Isolate CoreDNS Pods
Schedule CoreDNS pods on dedicated nodes and restrict access to these nodes, reducing the risk of compromise.

1. Monitor and Audit Changes
Continuously monitor and audit changes to the CoreDNS ConfigMap and related resources to detect unauthorized modifications promptly.

## Conclusion

DNS spoofing remains a common threat in Kubernetes environments. By understanding the attack vectors and implementing robust security measures, organisations can safeguard their clusters against such threats.


Kubernetes DNS Spoofing: Exploiting NET_RAW and ARP


## 🔍 Overview

In Part 1, we deployed a private Employee Directory API using Lambda, API Gateway and Interface Endpoints. Now, we’ll:

- Enable **secure cross-VPC access** using **VPC Peering** and **PrivateLink**
- Add **IAM-based SigV4 authentication** to protect the API

## 🌐 Cross-VPC Access with PrivateLink

If you want consumers in a **different VPC/account** to call your API:

### 1. **Enable Private DNS** (already done)

Ensure `private_dns_enabled = true` on your `aws_vpc_endpoint`.

### 2. **VPC Peering or Transit Gateway**

For same-account cross-VPC:

```go
resource "aws_vpc_peering_connection" "peer" {
  vpc_id        = aws_vpc.main.id
  peer_vpc_id   = aws_vpc.other.id
  auto_accept   = true
}

resource "aws_route" "to_peer" {
  route_table_id         = aws_route_table.main.id
  destination_cidr_block = aws_vpc.other.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.peer.id
}
```

For different-account, use **PrivateLink with NLB** + Endpoint Service (optional advanced setup).

## 🔐 Add IAM-Based Authentication

We now want **IAM-authenticated** access to our API.

### 1. Update API Gateway Method

```go
resource "aws_api_gateway_method" "get" {
  rest_api_id   = aws_api_gateway_rest_api.private_api.id
  resource_id   = aws_api_gateway_resource.employee.id
  http_method   = "GET"
  authorization = "AWS_IAM"
}
```

### 2. Create IAM Role for Client

```go
resource "aws_iam_user" "api_client" {
  name = "internal-api-client"
}

resource "aws_iam_policy" "invoke_api" {
  name   = "InvokePrivateAPI"
  policy = jsonencode({
    Version: "2012-10-17",
    Statement: [{
      Effect: "Allow",
      Action: "execute-api:Invoke",
      Resource: "arn:aws:execute-api:${var.region}:${data.aws_caller_identity.current.account_id}:${aws_api_gateway_rest_api.private_api.id}/*"
    }]
  })
}

resource "aws_iam_user_policy_attachment" "attach" {
  user       = aws_iam_user.api_client.name
  policy_arn = aws_iam_policy.invoke_api.arn
}
```

### 3. Test with SigV4

Install AWS CLI or use [awscurl](https://github.com/okigan/awscurl):

```bash
awscurl --service execute-api \
  --region us-east-1 \
  --access_key <AKIA...> \
  --secret_key <SECRET> \
  https://<rest-api-id>.execute-api.us-east-1.amazonaws.com/prod/employee/1002
```

You can now control access by IAM policies and optionally federate via Cognito/SAML if needed.

---

## ✅ Summary

We’ve now:

- Enabled secure cross-VPC access using PrivateLink/VPC peering
- Enforced IAM-based authentication using `AWS_IAM`
- Set up a realistic, secure, internal API stack

Next article: Add observability (CloudWatch Logs + X-Ray), throttling and versioned deployments with stages.

---


Extend your private API Gateway with secure access from other VPCs using PrivateLink and enforce IAM-based authentication.

Private API Gateway - Part 2: Secure Cross-VPC Access with PrivateLink and IAM Authentication


## 🔍 Overview

Private API Gateway allows you to expose REST APIs that are only accessible inside your VPC. No public internet access. This is ideal for internal microservices, backend systems, or APIs you want fully private.

### Scenario
We'll implement a secure internal **Employee Directory API** using AWS Lambda, API Gateway (private), and VPC Interface Endpoints. The API will be accessible **only inside the VPC**.

## 🧱 Prerequisites

- AWS CLI or Terraform
- A VPC with private subnets
- curl or Postman
- Basic understanding of:
  - API Gateway
  - Lambda
  - IAM
  - VPC endpoints (interface)

## 🛠️ Architecture

```
[ EC2 in VPC ] ---> [ VPC Endpoint ] ---> [ Private API Gateway ] ---> [ Lambda (Employee Directory) ]
```

Only resources inside the VPC can reach the API through the interface endpoint.

## 🔧 Step-by-Step Deployment (Terraform)

### 1. Create VPC, Subnet, and Security Group

```go
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_subnet" "private" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = false
}

resource "aws_security_group" "vpce_sg" {
  name        = "vpce-sg"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

### 2. Deploy the Lambda Function

Use the Python code below and package it:

```bash
mkdir employee-directory && cd employee-directory
vi index.py  # lets use our mini lambda below
zip employee_directory.zip index.py
```

```python
import json

EMPLOYEES = {
    "1001": {"id": "1001", "name": "Qais N", "role": "DevOps Engineer"},
    "1002": {"id": "1002", "name": "Abz Ab", "role": "Backend Engineer"},
    "1003": {"id": "1003", "name": "James John", "role": "Product Manager"},
}

def lambda_handler(event, context):
    path = event.get("path", "")
    method = event.get("httpMethod", "")

    if method == "GET" and path.startswith("/employee/"):
        emp_id = path.split("/")[-1]
        emp = EMPLOYEES.get(emp_id)
        if emp:
            return {"statusCode": 200, "body": json.dumps(emp)}
        return {"statusCode": 404, "body": json.dumps({"error": "Employee not found"})}

    if method == "GET" and path == "/employee":
        return {"statusCode": 200, "body": json.dumps(list(EMPLOYEES.values()))}

    return {"statusCode": 400, "body": json.dumps({"error": "Unsupported operation"})}
```

```go
resource "aws_iam_role" "lambda_exec" {
  name = "lambda_exec_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action = "sts:AssumeRole",
      Principal = { Service = "lambda.amazonaws.com" },
      Effect = "Allow",
    }],
  })
}

resource "aws_lambda_function" "employee_directory" {
  filename         = "employee_directory.zip"
  function_name    = "employee_directory"
  role             = aws_iam_role.lambda_exec.arn
  handler          = "index.lambda_handler"
  runtime          = "python3.9"
  source_code_hash = filebase64sha256("employee_directory.zip")
}
```

### 3. Create Private API Gateway and Integration

```go
resource "aws_api_gateway_rest_api" "private_api" {
  name        = "employee-directory-api"
  endpoint_configuration { types = ["PRIVATE"] }
}

resource "aws_api_gateway_resource" "employee" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  parent_id   = aws_api_gateway_rest_api.private_api.root_resource_id
  path_part   = "employee"
}

resource "aws_api_gateway_method" "get" {
  rest_api_id   = aws_api_gateway_rest_api.private_api.id
  resource_id   = aws_api_gateway_resource.employee.id
  http_method   = "GET"
  authorization = "NONE"
}

resource "aws_api_gateway_integration" "lambda_integration" {
  rest_api_id             = aws_api_gateway_rest_api.private_api.id
  resource_id             = aws_api_gateway_resource.employee.id
  http_method             = aws_api_gateway_method.get.http_method
  type                    = "AWS_PROXY"
  integration_http_method = "POST"
  uri                     = aws_lambda_function.employee_directory.invoke_arn
}
```

### 4. Configure VPC Endpoint and Policy

```go
resource "aws_vpc_endpoint" "api_gw" {
  vpc_id             = aws_vpc.main.id
  service_name       = "com.amazonaws.${var.region}.execute-api"
  vpc_endpoint_type  = "Interface"
  subnet_ids         = [aws_subnet.private.id]
  security_group_ids = [aws_security_group.vpce_sg.id]
}

resource "aws_api_gateway_deployment" "deployment" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  stage_name  = "prod"
  depends_on  = [aws_api_gateway_integration.lambda_integration]
}

resource "aws_api_gateway_rest_api_policy" "restrict_to_vpce" {
  rest_api_id = aws_api_gateway_rest_api.private_api.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Deny",
        Principal = "*",
        Action = "execute-api:Invoke",
        Resource = "*",
        Condition = {
          StringNotEquals = {
            "aws:SourceVpce" = aws_vpc_endpoint.api_gw.id
          }
        }
      }
    ]
  })
}
```

## 🧪 Test the Setup

1. SSH into an EC2 inside the VPC
2. Run:

```bash
curl https://<rest-api-id>.execute-api.<region>.amazonaws.com/prod/employee
curl https://<rest-api-id>.execute-api.<region>.amazonaws.com/prod/employee/1002
```

✅ Should return valid responses inside the VPC (inside EC2)
❌ Should be blocked from public internet

---

## 📌 Summary

- Built a fully private Employee Directory API
- Integrated it with Lambda + API Gateway
- Made it VPC-only using Interface Endpoints
- Secured access with SourceVpce IAM policy

Great for internal-only microservices, B2B APIs, or compliance-sensitive systems.

🧼 Destroy with:

```bash
terraform destroy
```

Part 2 coming out soon on: DynamoDB, PrivateLink cross-VPC, or IAM auth with SigV4!
---

Learn how to deploy a secure, private-only API Gateway inside your VPC using interface endpoints, resource policies, and VPC integration.

Securing APIs in AWS: Private API Gateway + VPC Endpoint Deep Dive


## 🔍 Overview

AWS PrivateLink enables secure, private connectivity between VPCs and services hosted on AWS without exposing traffic to the public internet. It's essential for secure service-to-service communication across accounts or VPCs.

In this post, we'll implement a working PrivateLink setup with Terraform: one VPC exposing a service (via NLB), and another VPC accessing it (via interface endpoint). We'll use two Terraform providers to simulate cross-account setup.

---

## 🛠️ Architecture

```
[ Service Provider VPC ]                  [ Service Consumer VPC ]
[ EC2 (httpd) ] -> [ NLB ] -> [ Endpoint Service ] <- [ VPC Endpoint ] <- [ EC2 ]
```

The service is hosted on a private EC2 behind a Network Load Balancer. An Endpoint Service is created from the NLB. The consumer VPC accesses it through an Interface VPC Endpoint.

---

## 🧱 Prerequisites

- Terraform ≥ 1.0
- Two AWS profiles or roles simulating service provider and consumer
- Basic networking knowledge (subnets, NLB, SGs)

---

## 🧩 Step 1: Service Provider VPC with NLB and Endpoint Service

```go
provider "aws" {
  alias  = "provider"
  region = "us-east-1"
}

resource "aws_vpc" "provider" {
  provider   = aws.provider
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "provider_subnet" {
  provider          = aws.provider
  vpc_id            = aws_vpc.provider.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}

resource "aws_security_group" "provider_sg" {
  provider = aws.provider
  vpc_id   = aws_vpc.provider.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "provider_instance" {
  provider        = aws.provider
  ami             = "ami-0c94855ba95c71c99"
  instance_type   = "t2.micro"
  subnet_id       = aws_subnet.provider_subnet.id
  security_groups = [aws_security_group.provider_sg.id]
  user_data       = <<-EOF
                #!/bin/bash
                echo "Hello from PrivateLink Service Provider" > index.html
                nohup python -m SimpleHTTPServer 80 &
                EOF
}

resource "aws_lb" "nlb" {
  provider           = aws.provider
  name               = "privatelink-nlb"
  internal           = true
  load_balancer_type = "network"
  subnets            = [aws_subnet.provider_subnet.id]
}

resource "aws_lb_target_group" "tg" {
  provider    = aws.provider
  name        = "privatelink-tg"
  port        = 80
  protocol    = "TCP"
  vpc_id      = aws_vpc.provider.id
  target_type = "instance"
}

resource "aws_lb_target_group_attachment" "tg_attachment" {
  provider         = aws.provider
  target_group_arn = aws_lb_target_group.tg.arn
  target_id        = aws_instance.provider_instance.id
  port             = 80
}

resource "aws_lb_listener" "listener" {
  provider          = aws.provider
  load_balancer_arn = aws_lb.nlb.arn
  port              = 80
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tg.arn
  }
}

resource "aws_vpc_endpoint_service" "service" {
  provider                    = aws.provider
  acceptance_required        = true
  network_load_balancer_arns = [aws_lb.nlb.arn]
}
```

---

## 🧩 Step 2: Service Consumer VPC with VPC Endpoint

```go
provider "aws" {
  alias  = "consumer"
  region = "us-east-1"
}

resource "aws_vpc" "consumer" {
  provider   = aws.consumer
  cidr_block = "10.1.0.0/16"
}

resource "aws_subnet" "consumer_subnet" {
  provider          = aws.consumer
  vpc_id            = aws_vpc.consumer.id
  cidr_block        = "10.1.1.0/24"
  availability_zone = "us-east-1a"
}

resource "aws_security_group" "consumer_sg" {
  provider = aws.consumer
  vpc_id   = aws_vpc.consumer.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["10.1.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_vpc_endpoint" "consumer_endpoint" {
  provider           = aws.consumer
  vpc_id             = aws_vpc.consumer.id
  service_name       = aws_vpc_endpoint_service.service.service_name
  vpc_endpoint_type  = "Interface"
  subnet_ids         = [aws_subnet.consumer_subnet.id]
  security_group_ids = [aws_security_group.consumer_sg.id]
}
```

---

## 🧪 Testing

- Accept the VPC Endpoint connection from the Provider side.
- SSH into an EC2 in the Consumer VPC and use:

```bash
curl http://<interface-endpoint-dns-name>
```

You should see:

```
Hello from PrivateLink Service Provider
```

---

## 🔐 Security Notes

- Ensure correct SGs between NLB and Endpoint
- Use IAM condition keys or resource policies if needed
- Enable VPC Flow Logs for visibility

---

## 📌 Summary

- We implemented AWS PrivateLink with real infra using Terraform
- Service is exposed internally via NLB and Interface Endpoint
- Setup is secure, scalable, and avoids internet exposure

Next steps? Add DNS, IAM auth, or cross-region routing!

---

A hands-on technical guide to implementing AWS PrivateLink between VPCs using Terraform.

Posts tagged with: security