GKE ClusterNetworkPolicy की मदद से वर्कलोड को सुरक्षित करना - एआई इन्फ़्रेंस का उदाहरण (Gemma, TPU)

1. खास जानकारी

इस लैब में, आपको Google Kubernetes Engine (GKE) पर ClusterNetworkPolicy के बारे में जानकारी मिलेगी. ClusterNetworkPolicy को अलग-अलग कामों के लिए लागू किया जाता है. इसे पूरे क्लस्टर पर लागू किया जा सकता है. साथ ही, इसे एडमिन और बेसलाइन टियर पर लागू किया जा सकता है. इस उदाहरण में, हम टीपीयू, vLLM, और पुष्टि करने की सुविधा के साथ GKE पर एलएलएम डिप्लॉयमेंट (Gemma) के साथ कंट्रोल करने का तरीका बताएंगे.

आपको इन टेक्नोलॉजी के साथ काम करना होगा:

  • Google Kubernetes Engine (GKE) — यह निजी और ज़रूरत के हिसाब से बढ़ाए जा सकने वाले वर्कलोड को होस्ट करने के लिए, कंटेनर ऑर्केस्ट्रेशन का बुनियादी प्लैटफ़ॉर्म है.
  • ClusterNetworkPolicy (CNP) — क्लस्टर के दायरे में आने वाली मल्टी-टियर नेटवर्क नीतियां, जो एडमिन, NetworkPolicy, और बेसलाइन टियर में SecOps गार्डरेल को चालू करती हैं.
  • vLLM TPU Inference Engine — OpenAI के साथ काम करने वाले REST एंडपॉइंट के साथ, Google TPU पर Gemma 4 के लाइटवेट मॉडल (google/gemma-4-E2B-it) को हाई-थ्रूपुट पर चलाने की सुविधा.

भूमिकाएं और पर्सोना

Network Policy API को संगठन के खास लोगों के हिसाब से बनाया गया है:

  • क्लस्टर एडमिन के लिए इस्तेमाल (ClusterNetworkPolicy): एडमिन और बेसलाइन टियर पर, क्लस्टर में सुरक्षा से जुड़े दिशा-निर्देश लागू करता है.
  • नेमस्पेस एडमिन (NetworkPolicy): यह खास नेमस्पेस में, टेनेंट-लेवल की सीमाओं और आइसोलेशन को मैनेज करता है.
  • ऐप्लिकेशन डेवलपर के लिए इस्तेमाल (NetworkPolicy): ऐप्लिकेशन के हिसाब से माइक्रोसेवाओं के लिए, बारीकी से नियम तय करता है.

इस एनवायरमेंट को कॉन्फ़िगर करने के लिए, आपको कस्टम प्राइवेट वीपीसी, Cloud NAT (एनएटी), और एक प्राइवेट GKE (जीकेई) क्लस्टर को डिप्लॉय करना होगा. इस क्लस्टर में एक खास TPU (टीपीयू) नोड पूल होना चाहिए.

अपने क्लस्टर को सुरक्षित करने के लिए, आपको स्टैंडर्ड NetworkPolicy ऑब्जेक्ट के साथ-साथ, मल्टी-टियर ClusterNetworkPolicy रिसॉर्स बनाने होंगे. इससे नेटवर्क के लिए सख्त सुरक्षा उपाय लागू किए जा सकेंगे. इसके बाद, आपको एआई वर्कलोड डिप्लॉय करना होगा. यह वर्कलोड, Gemma 4 मॉडल को इस्तेमाल करने के लिए, vLLM और Google Cloud TPU का इस्तेमाल करता है.

आखिर में, आपको एक वर्किंग बेसलाइन सेट अप करनी होगी, सुरक्षा से जुड़ी नीतियां लागू करनी होंगी, और Cloud Logging का इस्तेमाल करके NetworkLogging को कॉन्फ़िगर करना होगा. साथ ही, नीति से जुड़े फ़ैसलों का ऑडिट करने और पैकेट ड्रॉप की पुष्टि करने के लिए, लाइव Hubble eBPF observability स्ट्रीम का इस्तेमाल करना होगा. सभी कॉन्फ़िगरेशन में Terraform, gcloud, और kubectl. का कॉम्बिनेशन इस्तेमाल किया जाएगा

इस लैब में, आपको यह टास्क पूरा करने का तरीका पता चलेगा:

  • Terraform का इस्तेमाल करके, निजी नेटवर्किंग, GKE क्लस्टर, और Cloud TPU v5e एक्सेलरेटर को सेट अप करना.
  • कनेक्शन टेलीमेट्री को रिकॉर्ड करने के लिए, GKE NetworkLogging को कॉन्फ़िगर करें.
  • आधिकारिक vllm/vllm-tpu कंटेनर इमेज का इस्तेमाल करके, टीपीयू पर Gemma 4 E2B को डिप्लॉय करें.
  • पाबंदियां लागू करने से पहले, एंड-टू-एंड कनेक्टिविटी को साबित करने वाली एक वर्किंग बेसलाइन बनाएं.
  • Baseline-tier ClusterNetworkPolicy लागू करें, ताकि बिना अनुमति वाले क्रॉस-नेमस्पेस ट्रैफ़िक को डिफ़ॉल्ट रूप से अस्वीकार किया जा सके.
  • अनुमति वाले क्लाइंट को ऐक्सेस देने के लिए, डेवलपर की ओर से मैनेज की जाने वाली NetworkPolicy लागू करें.
  • Admin-tier ClusterNetworkPolicy लागू करें, ताकि ग्लोबल इग्रेस गार्डरेल लागू किए जा सकें. ये गार्डरेल, डेवलपर की सेटिंग को बदल देते हैं.
  • Hubble eBPF स्ट्रीम और Cloud Logging का इस्तेमाल करके, लाइव पैकेट ड्रॉप और पास की पुष्टि करें.

इस लैब में, आपको यह पैटर्न बनाना होगा.

Figure1. dbe5e5f7b35afb8e.jpeg

2. Google Cloud की सेवाओं का सेटअप

अपनी रफ़्तार से एनवायरमेंट सेटअप करना

  1. Google Cloud Console में साइन-इन करें और नया प्रोजेक्ट बनाएं या किसी मौजूदा प्रोजेक्ट का इस्तेमाल करें. अगर आपके पास पहले से कोई Gmail या Google Workspace खाता नहीं है, तो आपको एक खाता बनाना होगा.

295004821bab6a87.png37d264871000675d.png96d86d3d5655cdbe.png

  • प्रोजेक्ट का नाम, इस प्रोजेक्ट में हिस्सा लेने वाले लोगों के लिए डिसप्ले नेम होता है. यह एक वर्ण स्ट्रिंग है, जिसका इस्तेमाल Google API नहीं करते. इसे कभी भी अपडेट किया जा सकता है.
  • प्रोजेक्ट आईडी, Google Cloud के सभी प्रोजेक्ट के लिए यूनीक होता है. साथ ही, इसे बदला नहीं जा सकता. Cloud Console, अपने-आप एक यूनीक स्ट्रिंग जनरेट करता है. आम तौर पर, आपको यह जानने की ज़रूरत नहीं होती कि यह क्या है. ज़्यादातर कोडलैब में, आपको अपने प्रोजेक्ट आईडी (आम तौर पर, PROJECT_ID के तौर पर पहचाना जाता है) का रेफ़रंस देना होगा. अगर आपको जनरेट किया गया आईडी पसंद नहीं है, तो कोई दूसरा आईडी जनरेट किया जा सकता है. इसके अलावा, अपनी पसंद का कोई हैंडल डालकर देखें कि वह उपलब्ध है या नहीं. इस चरण के बाद, इसे बदला नहीं जा सकता. यह प्रोजेक्ट के खत्म होने तक लागू रहता है.
  • आपकी जानकारी के लिए बता दें कि एक तीसरी वैल्यू भी होती है, जिसे प्रोजेक्ट नंबर कहते हैं. कुछ एपीआई इसका इस्तेमाल करते हैं. इन तीनों वैल्यू के बारे में ज़्यादा जानने के लिए, दस्तावेज़ पढ़ें.
  1. इसके बाद, आपको Cloud Console में जाकर बिलिंग की सुविधा चालू करनी होगी, ताकि Cloud के संसाधनों/एपीआई का इस्तेमाल किया जा सके. इस कोडलैब को पूरा करने में आपको ज़्यादा खर्च नहीं करना पड़ेगा. इस ट्यूटोरियल के अलावा, बिलिंग से बचने के लिए संसाधनों को बंद किया जा सकता है. इसके लिए, बनाए गए संसाधनों या प्रोजेक्ट को मिटाया जा सकता है. Google Cloud के नए उपयोगकर्ता, 300 डॉलर के क्रेडिट के साथ मुफ़्त में आज़माने के प्रोग्राम में शामिल हो सकते हैं.

Cloud Shell चालू करना

Google Cloud को आपके लैपटॉप से रिमोटली ऑपरेट किया जा सकता है. हालांकि, इस कोडलैब में आपको Google Cloud Shell का इस्तेमाल करना होगा. यह क्लाउड में चलने वाला कमांड लाइन एनवायरमेंट है.

Google Cloud Console में जाकर, सबसे ऊपर दाईं ओर मौजूद टूलबार में Cloud Shell आइकॉन पर क्लिक करें:

Cloud Shell चालू करें

एनवायरमेंट को सेट अप करने और उससे कनेक्ट होने में कुछ ही समय लगना चाहिए. इसके पूरा होने पर, आपको कुछ ऐसा दिखेगा:

Google Cloud Shell टर्मिनल का स्क्रीनशॉट, जिसमें दिख रहा है कि एनवायरमेंट कनेक्ट हो गया है

इस वर्चुअल मशीन में, वे सभी डेवलपमेंट टूल मौजूद हैं जिनकी आपको ज़रूरत होगी. यह 5 जीबी की होम डायरेक्ट्री उपलब्ध कराता है और Google Cloud पर काम करता है. इससे नेटवर्क की परफ़ॉर्मेंस और पुष्टि करने की प्रोसेस बेहतर होती है. इस कोडलैब का सारा काम ब्राउज़र में किया जा सकता है. आपको कुछ भी इंस्टॉल करने की ज़रूरत नहीं है.

3. Terraform की मदद से एनवायरमेंट सेट अप करना

इस लैब को पूरा करने के लिए,

  • आपके पास चुने गए इलाके और ज़ोन में, TPU v5e के कोटे का ऐक्सेस होना चाहिए. उदाहरण के लिए, (us-central1-a, us-west4-a, us-south1-a, us-west1-c, europe-west4-b). ऐक्सेस पाने के लिए, आपको TPU प्लान के दस्तावेज़ में दिए गए निर्देशों का पालन करना चाहिए और TPU कोटा चालू करना चाहिए.
  • यह एक छोटा डिप्लॉयमेंट है, जिसके लिए चार TPU v5e चिप (ct5lp-hightpu-4t),) की ज़रूरत होती है. ये चिप, एक ही ज़ोन में 2x2 स्लाइस बनाएंगी.

Hugging Face का इस्तेमाल करने के लिए

  • Hugging Face टोकन: Gemma मॉडल के वेट डाउनलोड करने के लिए, ऐक्सेस टोकन की ज़रूरत होती है.
  • ज़रूरत के हिसाब से, इस्तेमाल के लिए कोई भी कानूनी समझौता स्वीकार करें.

हम फ़ायरवॉल के नियमों, सबनेट, और ऑटोपायलट क्लस्टर के साथ एक कस्टम वीपीसी बनाएंगे. Cloud Console खोलें और वह प्रोजेक्ट चुनें जिसका आपको इस्तेमाल करना है.

  1. अपने कंसोल में सबसे ऊपर दाईं ओर मौजूद, Cloud Shell खोलें. पक्का करें कि आपको Cloud Shell में सही प्रोजेक्ट आईडी दिख रहा हो. ऐक्सेस देने के लिए, किसी भी प्रॉम्प्ट की पुष्टि करें. b51b80043d3bac90.png
  2. gke-cnp-lab, नाम की डायरेक्ट्री बनाएं और उसमें जाएं.
mkdir -p gke-cnp-lab && cd gke-cnp-lab
  1. अब कुछ वैरिएबल बनाएं. ध्यान दें: REGION और ZONE में बदलाव करें, ताकि उस असल जगह की जानकारी दिखे जहां आपके पास TPU के संसाधनों का ऐक्सेस है. लैब के इलाके us-west4 और ज़ोन us-west4-a में इस्तेमाल किया गया डिफ़ॉल्ट
export PROJECT_ID=$(gcloud config get-value project)
export REGION="us-west4"
export ZONE="us-west4-a"
export NETWORK="cnp-demo-vpc"
export SUBNET="cnp-main-subnet"
export CLUSTER_NAME="cnp-demo-cluster"
  1. अपने कॉन्फ़िगरेशन वैरिएबल को gke-cnp-lab डायरेक्ट्री में मौजूद हेल्पर स्क्रिप्ट में सेव करें. अगर आपका Cloud Shell सेशन डिसकनेक्ट या रीसेट हो जाता है, तो source ./env.sh चलाकर अपने ऐक्टिव वैरिएबल को तुरंत वापस लाया जा सकता है
cat << EOF > env.sh
export PROJECT_ID="${PROJECT_ID}"
export REGION="${REGION}"
export ZONE="${ZONE}"
export NETWORK="${NETWORK}"
export SUBNET="${SUBNET}"
export CLUSTER_NAME="${CLUSTER_NAME}"

echo -e "\n=== Validating Environment Configuration ==="
echo "Project ID   : \${PROJECT_ID}"
echo "Region       : \${REGION}"
echo "Zone         : \${ZONE}"
echo "Network Name : \${NETWORK}"
echo "Subnet Name  : \${SUBNET}"
echo "Cluster Name : \${CLUSTER_NAME}"

if [[ -z "\${PROJECT_ID}" || -z "\${REGION}" || -z "\${ZONE}" || -z "\${NETWORK}" || -z "\${SUBNET}" || -z "\${CLUSTER_NAME}" ]]; then
  echo -e "\n[ERROR] One or more environment variables are missing! Check your configuration."
else
  echo -e "\n[SUCCESS] Environment variables successfully populated and validated."
fi
EOF

chmod +x env.sh
source ./env.sh
  1. अब कुछ कॉन्फ़िगरेशन फ़ाइलें जोड़ें. इससे gke-cnp-lab डायरेक्ट्री में, terraform.tfvars , variables.tf, और main.tf फ़ाइलें बन जाएंगी.
cat << EOF > terraform.tfvars
project_id   = "${PROJECT_ID}"
region       = "${REGION}"
zone         = "${ZONE}"
network_name = "${NETWORK}"
subnet_name  = "${SUBNET}"
cluster_name = "${CLUSTER_NAME}"
EOF

cat << 'EOF' > variables.tf
variable "project_id" {
  type        = string
  description = "Google Cloud Project ID"
}

variable "region" {
  type        = string
  description = "Target GCP region"
}

variable "zone" {
  type        = string
  description = "Target GCP zone"
}

variable "network_name" {
  type        = string
  description = "VPC network name"
}

variable "subnet_name" {
  type        = string
  description = "Subnetwork name"
}

variable "cluster_name" {
  type        = string
  description = "GKE cluster name"
}
EOF

cat << 'EOF' > main.tf
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 7.32.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = "~> 7.32.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

provider "google-beta" {
  project = var.project_id
  region  = var.region
}

# 1. Custom Private VPC Network
resource "google_compute_network" "vpc" {
  name                    = var.network_name
  auto_create_subnetworks = false
  mtu                     = 8896
}

# 2. Private Subnet with Secondary IP Ranges for Pods & Services
resource "google_compute_subnetwork" "subnet" {
  name                     = var.subnet_name
  ip_cidr_range            = "10.10.0.0/20"
  region                   = var.region
  network                  = google_compute_network.vpc.id
  private_ip_google_access = true

  secondary_ip_range {
    range_name    = "gke-pods"
    ip_cidr_range = "10.20.0.0/16"
  }
  secondary_ip_range {
    range_name    = "gke-services"
    ip_cidr_range = "10.30.0.0/20"
  }
}

# 3. Cloud Router & Cloud NAT for Secure Outbound Egress
resource "google_compute_router" "router" {
  name    = "${var.network_name}-router"
  network = google_compute_network.vpc.id
  region  = var.region
}

resource "google_compute_router_nat" "nat" {
  name                               = "${var.network_name}-nat"
  router                             = google_compute_router.router.name
  region                             = var.region
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

# 4. Internal Firewall Rules
resource "google_compute_firewall" "allow_internal" {
  name      = "${var.network_name}-allow-internal"
  network   = google_compute_network.vpc.id
  direction = "INGRESS"
  priority  = 1000
  allow {
    protocol = "all"
  }
  source_ranges = ["10.10.0.0/20", "10.20.0.0/16", "10.30.0.0/20"]
}

# 5. Private GKE Cluster with Observability and Dataplane V2
resource "google_container_cluster" "primary" {
  name               = var.cluster_name
  location           = var.region
  node_locations     = [var.zone]
  network            = google_compute_network.vpc.id
  subnetwork         = google_compute_subnetwork.subnet.id
  initial_node_count = 1

  datapath_provider = "ADVANCED_DATAPATH"

  # FIX: Observability config must be nested inside monitoring_config
  monitoring_config {
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }

  release_channel {
    channel = "RAPID"
  }

  ip_allocation_policy {
    cluster_secondary_range_name  = "gke-pods"
    services_secondary_range_name = "gke-services"
  }

  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }

  node_config {
    machine_type = "e2-standard-4"
    oauth_scopes = ["https://www.googleapis.com/auth/cloud-platform"]
  }

  deletion_protection = false
}

# 6. Dedicated Cloud TPU v5e Node Pool (ct5lp-hightpu-4t / 2x2 Topology)
resource "google_container_node_pool" "tpu_pool" {
  provider       = google-beta
  name           = "tpu-v5e-pool"
  location       = var.region
  node_locations = [var.zone]
  cluster        = google_container_cluster.primary.name
  node_count     = 1

  node_config {
    machine_type = "ct5lp-hightpu-4t"
    oauth_scopes = ["https://www.googleapis.com/auth/cloud-platform"]

    labels = {
      "cloud.google.com/gke-tpu-accelerator" = "tpu-v5-lite-podslice"
      "cloud.google.com/gke-tpu-topology"    = "2x2"
    }

    taint {
      key    = "google.com/tpu"
      value  = "present"
      effect = "NO_SCHEDULE"
    }
  }
}
EOF
  1. पक्का करें कि आप gke-cnp-lab डायरेक्ट्री में हों. इसके बाद, ये कमांड चलाएं
    terraform init इससे वर्किंग डायरेक्ट्री शुरू हो जाती है. यह पहला चरण है. इसमें, दिए गए कॉन्फ़िगरेशन के लिए ज़रूरी प्रोवाइडर डाउनलोड किए जाते हैं.
    terraform plan -out, एक्ज़ीक्यूशन प्लान जनरेट करता है. इससे पता चलता है कि Terraform, आपके इन्फ़्रास्ट्रक्चर को डिप्लॉय करने के लिए क्या कार्रवाइयां करेगा. -out की मदद से, एक्ज़ीक्यूशन प्लान को किसी नाम वाली बाइनरी में सेव किया जा सकता है. कोई बदलाव किए बिना, यह देखा जा सकता है कि क्या होगा.
    terraform apply अपडेट लागू करता है.
terraform init 
terraform plan -out cnpgke
  1. एक्ज़ीक्यूशन प्लान लागू करें. सेव किए गए एक्ज़ीक्यूशन प्लान को लागू करने पर, यह पुष्टि के लिए पूछे बिना तुरंत लागू हो जाएगा (इसमें 6 से 10 मिनट लग सकते हैं)
terraform apply cnpgke
  1. अपने इन्फ़्रास्ट्रक्चर डिप्लॉयमेंट की पुष्टि करें:
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION} --project=${PROJECT_ID}
echo -e "\n=== Verifying Cluster Nodes ==="
kubectl get nodes -L cloud.google.com/gke-tpu-accelerator,cloud.google.com/gke-tpu-topology

8b187e355548b7c5.png

4. नेटवर्क लॉगिंग को कॉन्फ़िगर करना

वर्कलोड और नीतियां लागू करने से पहले, GKE नेटवर्क लॉगिंग को कॉन्फ़िगर करें. इससे Cloud Logging में, कनेक्शन टेलीमेट्री और ऑडिट नीति से जुड़े फ़ैसलों को रिकॉर्ड किया जा सकेगा.

  1. gke-cnp-lab डायरेक्ट्री में, NetworkLogging कॉन्फ़िगरेशन मेनिफ़ेस्ट बनाएं
cat << 'EOF' > 00-network-logging.yaml
apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      delegate: false
      log: true
    deny:
      delegate: false
      log: true
EOF
  1. क्लस्टर पर कॉन्फ़िगरेशन लागू करना
kubectl apply -f 00-network-logging.yaml
kubectl get networklogging default

ध्यान दें: आपको एक चेतावनी दिख सकती है. इसमें बताया गया होगा कि संसाधन में kubectl.kubernetes.io/last-applied-configuration annotation. मौजूद नहीं है. यह पूरी तरह से सामान्य है और इसकी उम्मीद की जा सकती है! क्लस्टर के चालू होने पर, GKE पहले से ही एक डिफ़ॉल्ट NetworkLogging ऑब्जेक्ट बना देता है. साथ ही, kubectl apply आपके नए नियमों को लागू करने के लिए, इसके मैनेजमेंट को अपने कंट्रोल में ले लेता है.

5. Gemma 4 वर्कलोड और क्लाइंट प्रोब डिप्लॉय करना

आपको अलग-अलग नेमस्पेस बनाने होंगे, ताकि कई लेवल पर नीतियों के आकलन की जांच की जा सके:

  • gemma-llm: इसमें Gemma 4 का मुख्य अनुमान वर्कलोड (tier: ai-core) होता है.
  • client-ns: इसमें अनुमति वाला आरएजी चैट क्लाइंट (tier: app-frontend) मौजूद होता है.
  • untrusted-tenant: इसमें बिना अनुमति वाला प्रोब कंटेनर (tier: untrusted) मौजूद है.
  1. gke-cnp-lab directory, में, नेमस्पेस और टेस्ट क्लाइंट पॉड वाला 01-namespaces-clients.yaml मेनिफ़ेस्ट बनाएं:
cat << 'EOF' > 01-namespaces-clients.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: gemma-llm
  labels:
    tier: ai-core
---
apiVersion: v1
kind: Namespace
metadata:
  name: client-ns
  labels:
    tier: app-frontend
---
apiVersion: v1
kind: Namespace
metadata:
  name: untrusted-tenant
  labels:
    tier: untrusted
---
# Authorized Client Pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rag-agent-client
  namespace: client-ns
  labels:
    app: rag-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rag-agent
  template:
    metadata:
      labels:
        app: rag-agent
    spec:
      containers:
        - name: client
          image: curlimages/curl:latest
          command: ["/bin/sh", "-c", "sleep 86400"]
---
# Rogue / Untrusted Probe Pod
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rogue-client
  namespace: untrusted-tenant
  labels:
    app: rogue-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rogue-app
  template:
    metadata:
      labels:
        app: rogue-app
    spec:
      containers:
        - name: probe
          image: curlimages/curl:latest
          command: ["/bin/sh", "-c", "sleep 86400"]
EOF
  • नेमस्पेस और क्लाइंट डिप्लॉयमेंट लागू करें:
kubectl apply -f 01-namespaces-clients.yaml
kubectl get namespaces gemma-llm client-ns untrusted-tenant --show-labels

vLLM और Gemma वर्कलोड को डिप्लॉय करना

Hugging Face का सीक्रेट बनाएं. YOUR_ACTUAL_HUGGING_FACE_TOKEN को अपने टोकन से बदलें:

export HF_TOKEN="YOUR_ACTUAL_HUGGING_FACE_TOKEN"
echo $HF_TOKEN
kubectl create secret generic hf-secret -n gemma-llm --from-literal=hf_token=${HF_TOKEN}
  1. vllm-tpu का इस्तेमाल करके, Cloud TPU v5e को टारगेट करने वाला Gemma 4 का अनुमान लगाने वाला वर्कलोड मेनिफ़ेस्ट बनाएं:
cat << 'EOF' > 02-gemma4-tpu-vllm.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gemma-serving
  namespace: gemma-llm
  labels:
    app: gemma-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gemma-service
  template:
    metadata:
      labels:
        app: gemma-service
        ai.gke.io/model: gemma4
        ai.gke.io/inference-server: vllm-tpu
    spec:
      tolerations:
        - key: "google.com/tpu"
          operator: "Exists"
          effect: "NoSchedule"
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
        cloud.google.com/gke-tpu-topology: 2x2
      containers:
        - name: vllm-inference
          image: vllm/vllm-tpu:latest
          command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
          args:
            - "--model=google/gemma-4-E2B-it"
            - "--tensor-parallel-size=4"
            - "--host=0.0.0.0"
            - "--port=8000"
            - "--max-model-len=4096"
            - "--max-num-batched-tokens=4096"
          env:
            - name: HF_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-secret
                  key: hf_token
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-secret
                  key: hf_token
          volumeMounts:
            - mountPath: /dev/shm
              name: dshm
          ports:
            - name: http-inference
              containerPort: 8000
          resources:
            requests:
              google.com/tpu: "4"
              memory: "32Gi"
              cpu: "8"
            limits:
              google.com/tpu: "4"
              memory: "32Gi"
              cpu: "8"
          startupProbe:
            httpGet:
              path: /health
              port: 8000
            failureThreshold: 120
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 5
      volumes:
        - name: dshm
          emptyDir:
            medium: Memory
---
apiVersion: v1
kind: Service
metadata:
  name: gemma-service
  namespace: gemma-llm
spec:
  type: ClusterIP
  selector:
    app: gemma-service
  ports:
    - name: http
      protocol: TCP
      port: 8000
      targetPort: 8000
EOF
  1. डिप्लॉयमेंट बनाएं.
kubectl apply -f 02-gemma4-tpu-vllm.yaml
  1. टास्क पूरा होने की स्थिति पर नज़र रखने के लिए, यहां दी गई स्क्रिप्ट चलाएं. पॉड तब तक इंतज़ार करेंगे, जब तक नोड को प्रोविज़न नहीं कर दिया जाता. इसमें 13 मिनट से ज़्यादा लग सकते हैं.
echo "       __|__"
echo "  --@--(_|_)--@--"
echo ""
echo "Waiting for Gemma 4 TPU Pod to initialize and become Ready..."

# 1. Wait for the pod to be scheduled and reach the Running state
kubectl wait -n gemma-llm --for=condition=Ready pod -l app=gemma-service --timeout=600s

echo ""
echo "✅ Pod is Running! Streaming vLLM engine initialization logs..."

# 2. Stream logs until Uvicorn/vLLM is ready to serve
kubectl logs -n gemma-llm -l app=gemma-service -c vllm-inference -f | sed -u '/Application startup complete/q'

echo ""
echo "🚀 Gemma 4 on TPU v5e is ready for inference!"

6. नीति के आकलन और डिफ़ॉल्ट स्थिति के बारे में जानकारी

नेटवर्क से जुड़ी नीतियां लागू करने से पहले, यह समझें कि GKE ClusterNetworkPolicy और स्टैंडर्ड Kubernetes NetworkPolicy, अलग-अलग इवैलुएशन टियर में कैसे इंटरैक्ट करते हैं.

GKE में ट्रैफ़िक का आकलन, कई लेवल वाले प्राथमिकता मॉडल के ज़रिए किया जाता है:

Admin Tier ⟶ NetworkPolicy Tier ⟶ Baseline Tier ⟶ Default GKE Behavior

d4cf83398c69b6b8.png

जांच करने का हमारा तरीका

===================================================
           4-STAGE POLICY EVALUATION FLOW
===================================================

[Stage 1: Default State]
 ├── Pre-Policy State: Default Kubernetes allow-all
 ├── Ingress: client-ns  ──▶ Gemma 4: ALLOWED (200 OK)
 ├── Ingress: untrusted  ──▶ Gemma 4: ALLOWED (200 OK)
 ├── Egress:  All Pods   ──▶ Metadata: ALLOWED (Exposed)
 └── Security Posture: ⚠️ Overly permissive
      │
      ▼
[Stage 2: Baseline Lockdown]
 ├── Policy: ClusterNetworkPolicy (tier: Baseline)
 ├── Rule: Default-deny all cross-namespace ingress
 ├── Ingress: client-ns  ──▶ Gemma 4: DROPPED (Timeout)
 ├── Ingress: untrusted  ──▶ Gemma 4: DROPPED (Timeout)
 └── Security Posture: 🛑 Zero-trust baseline active
      │
      ▼
[Stage 3: Developer Delegation]
 ├── Policy: NetworkPolicy (tier: NetworkPolicy)
 ├── Rule: App team allows ingress from client-ns
 ├── Ingress: client-ns  ──▶ Gemma 4: ALLOWED (200 OK)
 ├── Ingress: untrusted  ──▶ Gemma 4: DROPPED (Timeout)
 └── Security Posture: 🔀 App isolation achieved
      │
      ▼
[Stage 4: Admin Guardrail]
 ├── Policy: ClusterNetworkPolicy (tier: Admin)
 ├── Rule: Cluster-wide metadata drop (169.254.169.254)
 ├── Egress:  All Pods   ──▶ Metadata: DROPPED (Timeout)
 ├── Dev NetPol bypass attempt:   OVERRIDDEN (Blocked)
 └── Security Posture: 🔒 Enforced guardrail
===================================================

बेसलाइन फ़ाउंडेशन सेट अप करना (नीति लागू होने से पहले की जांच)

पुष्टि करें कि Gemma 4 मॉडल सही तरीके से काम कर रहा है और अनुमान लगाने के अनुरोधों को पूरा कर रहा है. बिना नीतियों वाले स्टैंडर्ड Kubernetes में, सभी क्रॉस-नेमस्पेस ट्रैफ़िक को अनुमति दी जाती है.

  1. client-ns में अनुमति पा चुके क्लाइंट से टेस्ट अनुमान:
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'
  1. untrusted-tenant में, बिना अनुमति वाले क्लाइंट से टेस्ट अनुमान:
kubectl exec -n untrusted-tenant deploy/rogue-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'
  1. जांच करें कि तीनों नेमस्पेस के पॉड, मेटाडेटा सर्वर (169.254.169.254) तक पहुंच सकते हैं या नहीं:
echo -e "\n[1/3] Testing Metadata access from Gemma serving pod (gemma-llm)..."
kubectl exec -n gemma-llm deploy/gemma-serving -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"

echo -e "\n[2/3] Testing Metadata access from authorized client (client-ns)..."
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"

echo -e "\n[3/3] Testing Metadata access from rogue client (untrusted-tenant)..."
kubectl exec -n untrusted-tenant deploy/rogue-client -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"

7. आकलन के लिए टेस्ट बेसलाइन और नेटवर्क की नीति का टियर

इस चरण में, क्लस्टर एडमिन के तौर पर, आपको बेसलाइन-टियर ClusterNetworkPolicy लागू करना होगा. इससे पूरे क्लस्टर के लिए, फ़ॉलबैक डिफ़ॉल्ट-डिनाइ पॉस्चर सेट किया जा सकेगा. अगर किसी नेमस्पेस के बीच होने वाले कम्यूनिकेशन को किसी हाई टियर से अनुमति नहीं मिली है, तो उसे ड्रॉप कर दिया जाएगा.

ज़ीरो-ट्रस्ट पॉस्चर (बेसलाइन टियर) सेट अप करना

  1. 03-baseline-deny.yaml बेसलाइन-टियर नीति मेनिफ़ेस्ट बनाएं:
cat << 'EOF' > 03-baseline-deny.yaml
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: baseline-default-deny
spec:
  tier: Baseline
  priority: 1000
  subject:
    namespaces: {}
  ingress:
    # 1. Allow CoreDNS Ingress cluster-wide so DNS resolution never breaks
    - name: allow-dns-ingress
      action: Accept
      from:
        - namespaces: {}
      protocols:
        - udp:
            destinationPort:
              number: 53
        - tcp:
            destinationPort:
              number: 53
    # 2. Default Deny all other cross-namespace ingress
    - name: baseline-deny-cross-ns
      action: Deny
      from:
        - namespaces: {}
EOF
  1. Baseline टियर की नीति लागू करें:
kubectl apply -f 03-baseline-deny.yaml
  1. client-ns. से क्लाइंट कनेक्टिविटी की जांच करना
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'
  1. बिना अनुमति वाले क्लाइंट से, भरोसेमंद न होने वाले टेनेंट में अनुमान लगाने की जांच करना:
kubectl exec -n untrusted-tenant deploy/rogue-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'

डेवलपर को ऐक्सेस देना (NetworkPolicy टियर)

gemma-llm ऐप्लिकेशन टीम अब स्टैंडर्ड नेमस्पेस-स्कोप वाली NetworkPolicy लागू करेगी, ताकि client-ns से अनुमति वाले ट्रैफ़िक को अनुमति दी जा सके.

  1. डेवलपर 04-app-networkpolicy.yaml NetworkPolicy मेनिफ़ेस्ट बनाएं:
cat << 'EOF' > 04-app-networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-rag-client
  namespace: gemma-llm
spec:
  podSelector:
    matchLabels:
      app: gemma-service
  policyTypes:
    - Ingress
  ingress:
    # Explicitly permit ingress only from pods matching app: rag-agent in client-ns
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: client-ns
          podSelector:
            matchLabels:
              app: rag-agent
      ports:
        - protocol: TCP
          port: 8000
EOF
  1. नीति लागू करें:
kubectl apply -f 04-app-networkpolicy.yaml
  1. client-ns से क्लाइंट कनेक्टिविटी की जांच करना
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'
  1. untrusted-tenant में, नकली क्लाइंट से कनेक्टिविटी की जांच करें:
kubectl exec -n untrusted-tenant deploy/rogue-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'

8. आकलन के दौरान, ग्लोबल गार्डरेल (एडमिन टियर) लागू किए जाते हैं

क्लस्टर एडमिन के तौर पर, अब आपको GKE के आकलन के क्रम में सबसे ऊपर, एडमिन-टियर ClusterNetworkPolicy लागू करना होगा. इस टियर का आकलन सबसे पहले किया जाता है. मैच करने वाले किसी भी नियम को अन्य सभी टियर के मुकाबले तुरंत प्राथमिकता दी जाती है. अगर कोई मैच नहीं मिलता है, तो पैकेट को निचले लेवल (NetworkPolicy और Baseline) पर जांच के लिए भेज दिया जाता है.

इस चरण में, आपको ऐसी नीति लागू करनी होगी जो:

  • क्लस्टर-वाइड इग्रेस गार्डरेल: यह हर नेमस्पेस में मौजूद सभी पॉड को Google Cloud Metadata Server (169.254.169.254/32) तक पहुंचने से रोकता है.
  • डीएनएस सपोर्ट: पोर्ट 53 पर सभी डीएनएस ट्रैफ़िक को अनुमति देता है, ताकि पॉड होस्टनेम को रिज़ॉल्व कर सकें. इसमें GKE के लोकल डीएनएस कैश मेमोरी को ध्यान में रखा जाता है.
  • इनग्रेस और इग्रेस डेलिगेशन: यह Pass कार्रवाई का इस्तेमाल करके, ट्रैफ़िक से जुड़े अन्य सभी फ़ैसले आगे भेजता है. इससे डेवलपर नेटवर्क की स्टैंडर्ड नीतियां और डिफ़ॉल्ट रूप से अस्वीकार करने के बुनियादी नियम, आखिरी फ़ैसले ले सकते हैं.
  1. सभी नेमस्पेस को टारगेट करने वाली 05-admin-guardrails.yaml एडमिन-टियर नीति मेनिफ़ेस्ट बनाएं
cat << 'EOF' > 05-admin-guardrails.yaml
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: admin-global-guardrails
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces: {}
  ingress:
    - name: delegate-all-ingress
      action: Pass
      from:
        - namespaces: {}
  egress:
    - name: allow-all-dns
      action: Accept
      to:
        - networks:
            - 0.0.0.0/0
      protocols:
        - udp:
            destinationPort:
              number: 53
        - tcp:
            destinationPort:
              number: 53
    - name: block-metadata-server-global
      action: Deny
      to:
        - networks:
            - 169.254.169.254/32
    - name: delegate-other-egress
      action: Pass
      to:
        - namespaces: {}
EOF
  1. एडमिन टियर की नीति लागू करें:
kubectl apply -f 05-admin-guardrails.yaml
  1. तीनों नेमस्पेस में, मेटाडेटा को बाहर निकालने की जांच करें:
echo -e "\n[1/3] Testing Metadata access from Gemma serving pod (gemma-llm)..."
kubectl exec -n gemma-llm deploy/gemma-serving -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"

echo -e "\n[2/3] Testing Metadata access from authorized client (client-ns)..."
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"

echo -e "\n[3/3] Testing Metadata access from rogue client (untrusted-tenant)..."
kubectl exec -n untrusted-tenant deploy/rogue-client -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Blocked)"
  1. client-ns से क्लाइंट कनेक्टिविटी की जांच करना
kubectl exec -n client-ns deploy/rag-agent-client -- curl --connect-timeout 3 -s -X POST \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/gemma-4-E2B-it",
    "messages": [{"role": "user", "content": "Explain zero trust in one short sentence."}],
    "max_tokens": 40
  }' | jq -r '.choices[0].message.content'
  1. gemma-llm में, सभी को अनुमति देने वाली इग्रेस NetworkPolicy लागू करके, डेवलपर के बायपास करने की कोशिश को सिम्युलेट करें:
cat << 'EOF' > 06-bypass-attempt.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dev-allow-all-egress
  namespace: gemma-llm
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - {}
EOF

kubectl apply -f 06-bypass-attempt.yaml
  1. यह जांच करें कि डेवलपर बायपास, मेटाडेटा के ऐक्सेस को अनब्लॉक कर सकता है या नहीं:
kubectl exec -n gemma-llm deploy/gemma-serving -- curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "🛑 RESULT: Connection Timed Out (Admin Guardrail Overrode Developer Policy)"

9. Hubble और Cloud Logging की मदद से, इंटरैक्टिव तरीके से पुष्टि करना

अपने क्लस्टर में रीयल-टाइम में नीति लागू करने और ऑडिट पैकेट के फ़ैसलों को देखने के लिए, Dual-Pane Cloud Shell सेशन का इस्तेमाल किया जाएगा. इसमें कर्नल-लेवल eBPF पैकेट ट्रेसिंग को ऑटोमेटेड टेस्ट एक्ज़ीक्यूशन के साथ जोड़ा जाएगा.

  1. दूसरा टर्मिनल टैब खोलने के लिए, Cloud Shell मेन्यू में "+" आइकॉन पर क्लिक करें.
  2. इस नए टैब में, एलियस बनाने और gemma-llm नेमस्पेस के लिए लाइव ट्रैफ़िक को मॉनिटर करने के लिए, ये कमांड चलाएं:
# Create an alias to execute Hubble natively inside the relay pod
alias hubble="kubectl exec -it -n gke-managed-dpv2-observability deploy/hubble-relay -c hubble-cli -- hubble"

# Observe real-time traffic to and from the Gemma namespace
hubble observe --follow --namespace gemma-llm
  1. अपने पहले Cloud Shell टैब पर वापस जाएं और पक्का करें कि आप gke-cnp-lab डायरेक्ट्री में हों
cd ~/gke-cnp-lab
  1. पुष्टि करने की प्रोसेस को ऑटोमेट करने वाली स्क्रिप्ट बनाने और उसे चलाने के लिए, यह ब्लॉक चलाएं. यह स्क्रिप्ट, ज़रूरी ट्रैफ़िक टेस्ट चलाती है और GKE के सटीक रूट-लेवल मेटाडेटा स्कीमा का इस्तेमाल करके, Cloud Logging से क्वेरी करती है. इससे Dataplane V2 के उन सटीक नियमों को दिखाया जाता है जिनके आधार पर अनुरोधों का आकलन किया गया था:
cat << 'EOF' > verify-suite.sh
#!/usr/bin/env bash
set -e

echo "========================================================"
echo " 🧪 RUNNING MULTI-TIER POLICY VERIFICATION SUITE"
echo "========================================================"

# Test 1: Ingress Authorized Client -> Gemma (Allowed by NetworkPolicy)
echo -e "\n[1/5] Testing Authorized Client -> Gemma Serving..."
if kubectl exec -n client-ns deploy/rag-agent-client -- \
  curl -s --connect-timeout 3 \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions > /dev/null; then
  echo "  ✅ RESULT: FORWARDED (Allowed by Developer Network Policy)"
else
  echo "  🛑 RESULT: FAILED"
fi

# Test 2: Ingress Rogue Client -> Gemma (Blocked by Baseline Tier)
echo -e "\n[2/5] Testing Unauthorized Rogue Tenant -> Gemma Serving..."
if kubectl exec -n untrusted-tenant deploy/rogue-client -- \
  curl -s --connect-timeout 3 \
  http://gemma-service.gemma-llm.svc.cluster.local:8000/v1/chat/completions > /dev/null; then
  echo "  ⚠️ RESULT: UNEXPECTED ALLOW"
else
  echo "  🛑 RESULT: DROPPED (Blocked by Baseline Tier)"
fi

# Test 3: Egress Gemma -> GCP Metadata Server (Blocked by Admin Tier)
echo -e "\n[3/5] Testing Metadata access from Gemma serving pod (gemma-llm)..."
kubectl exec -n gemma-llm deploy/gemma-serving -- \
  curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "  🛑 RESULT: Connection Timed Out (Blocked)"

# Test 4: Egress Authorized Client -> GCP Metadata Server (Blocked by Admin Tier)
echo -e "\n[4/5] Testing Metadata access from authorized client (client-ns)..."
kubectl exec -n client-ns deploy/rag-agent-client -- \
  curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "  🛑 RESULT: Connection Timed Out (Blocked)"

# Test 5: Egress Rogue Client -> GCP Metadata Server (Blocked by Admin Tier)
echo -e "\n[5/5] Testing Metadata access from rogue client (untrusted-tenant)..."
kubectl exec -n untrusted-tenant deploy/rogue-client -- \
  curl --connect-timeout 3 -s -w "\nHTTP Code: %{http_code}\n" -H "Metadata-Flavor: Google" \
  http://169.254.169.254/computeMetadata/v1/instance/zone || echo "  🛑 RESULT: Connection Timed Out (Blocked)"

echo -e "\n========================================================"
echo " 📋 FETCHING AUDIT TRAIL FROM CLOUD LOGGING"
echo "========================================================"
echo "Waiting 12 seconds for telemetry ingestion..."
sleep 12

echo -e "\n🔍 1. Validating Baseline Tier (Rogue Client Block):"
gcloud logging read '
  resource.type="k8s_node"
  logName=~"logs/policy-action"
  jsonPayload.disposition="deny"
  jsonPayload.src.namespace="untrusted-tenant"
  jsonPayload.dest.namespace="gemma-llm"
' --limit=1 --format="table(
    timestamp.date('%H:%M:%S', tz=LOCAL):label=TIME,
    jsonPayload.src.namespace:label=SRC_NS,
    jsonPayload.dest.namespace:label=DEST_NS,
    jsonPayload.policies[0].name:label=BLOCKED_BY_POLICY
)"

echo -e "\n🔍 2. Validating Admin Tier (Metadata Block across all namespaces):"
gcloud logging read '
  resource.type="k8s_node"
  logName=~"logs/policy-action"
  jsonPayload.disposition="deny"
  jsonPayload.connection.dest_ip="169.254.169.254"
' --limit=3 --format="table(
    timestamp.date('%H:%M:%S', tz=LOCAL):label=TIME,
    jsonPayload.src.namespace:label=SRC_NS,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.policies[0].name:label=BLOCKED_BY_POLICY
)"
EOF

chmod +x verify-suite.sh
./verify-suite.sh
  1. जब स्क्रिप्ट आपके पहले टैब में चल रही हो, तब दूसरे टैब में Hubble का आउटपुट देखें.

Hubble (टैब 2) में: आपको अनुमति वाले एचटीटीपी अनुरोध, हरे रंग में फ़ॉरवर्ड होते हुए दिखेंगे. ब्लॉक किए गए ट्रैफ़िक के लिए, आपको लाल रंग के (DROPPED) इवेंट दिखेंगे. The Rogue Tenant: कनेक्शन को एडमिन टियर से पास किया जाता है और बेसलाइन टियर पर ब्लॉक किया जाता है. मेटाडेटा क्वेरी: क्लाउड क्रेडेंशियल को ऐक्सेस करने के इसके अनुरोध को एडमिन टियर पर तुरंत ब्लॉक कर दिया जाता है.

7d68cc0e9b90f820.png

Cloud Logging में (टैब 1): स्क्रिप्ट, Google Cloud Logging को भेजे गए ऑडिट रिकॉर्ड को फ़ेच करके खत्म होती है. इससे साफ़ तौर पर पता चलता है कि किस टियर (एडमिन या बेसलाइन) और किस नीति की वजह से, बिना अनुमति वाले ट्रैफ़िक को रोका गया. साथ ही, इसमें स्थानीय जगह और टाइमज़ोन के हिसाब से टाइमस्टैंप भी शामिल होते हैं.

b9e48fd473451ca2.png

10. व्यवस्थित करें

  1. दूसरा टैब बंद करना
  2. अपने पहले Cloud Shell टैब पर वापस जाएं.
  3. डिप्लॉय किए गए Kubernetes मेनिफ़ेस्ट, नेमस्पेस, और सीक्रेट को इस क्रम में मिटाएं:
cd ~/gke-cnp-lab

# Delete policy and verification scripts
rm -f verify-suite.sh
kubectl delete -f 05-admin-guardrails.yaml --ignore-not-found
kubectl delete -f 04-app-networkpolicy.yaml --ignore-not-found
kubectl delete -f 03-baseline-deny.yaml --ignore-not-found
kubectl delete -f 00-network-logging.yaml --ignore-not-found

# Delete workload deployments, secrets, and namespaces
kubectl delete -f 02-gemma4-tpu-vllm.yaml --ignore-not-found
kubectl delete secret hf-secret -n gemma-llm --ignore-not-found
kubectl delete -f 01-namespaces-clients.yaml --ignore-not-found
  1. इस कमांड का इस्तेमाल करके, इन्फ़्रास्ट्रक्चर को क्लीन अप करें. पुष्टि करने के लिए, yes टाइप करें
terraform destroy --auto-approve
  1. पुष्टि करें कि आपके चालू प्रोजेक्ट में सभी संसाधन पूरी तरह से बंद कर दिए गए हैं:
gcloud container clusters list --region=us-west4
gcloud compute networks list
  1. gke-cnp-lab डायरेक्ट्री और कॉन्टेंट मिटाएं:
cd
rm -r gke-cnp-lab

11. बधाई हो

आपने GKE ClusterNetworkPolicy कोडलैब की मदद से, Secure AI Inference Workloads को पूरा कर लिया है!

इस लैब को पूरा करके, आपने Google Kubernetes Engine पर संवेदनशील निजी एलएलएम वर्कलोड को मैनेज करने के लिए, कई लेयर वाली मज़बूत सुरक्षा वाला नेटवर्क आर्किटेक्चर डिज़ाइन किया है और उसकी पुष्टि की है.

आपने क्या हासिल किया:

  • इन्फ़्रास्ट्रक्चर ऐज़ कोड: Terraform का इस्तेमाल करके, डाइनैमिक तौर पर एक सुरक्षित निजी स्टैंडर्ड GKE क्लस्टर, एक निजी रीजनल सबनेट, और Cloud TPU v5e हार्डवेयर को उपलब्ध कराया गया.
  • टेलीमेट्री और जांचने की क्षमता: Dataplane V2 नेटवर्क लॉगिंग को कॉन्फ़िगर किया गया. साथ ही, कर्नल-लेवल के eBPF Hubble ट्रेसिंग को कॉन्फ़िगर किया गया, ताकि रनटाइम पैकेट की पूरी जानकारी मिल सके.
  • क्रम के हिसाब से सुरक्षा की स्थिति: उदाहरण के लिए, आकलन के तीन अलग-अलग टियर में, ऑपरेशन से जुड़ी ज़िम्मेदारियों को साफ़ तौर पर अलग-अलग करना:
  • एडमिन टियर: पूरे क्लस्टर में लागू किए गए, बायपास न किए जा सकने वाले इग्रेस गार्डरेल, जो लैटरल मेटाडेटा क्रेडेंशियल ऐक्सेस (169.254.169.254) को ब्लॉक करते हैं.
  • NetworkPolicy टियर: ऐप्लिकेशन डेवलपर को नेमस्पेस के दायरे में आने वाली इन्ग्रेस डेटा ट्रैफ़िक की सीमाएं सौंपी गई हैं, ताकि वे प्रोडक्शन क्लाइंट कनेक्शन को सुरक्षित तरीके से अनुमति दे सकें.
  • बेसलाइन टियर: हमने क्लस्टर-वाइड फ़ॉलबैक सुरक्षा नेट बनाया है, जो बिना अनुमति वाले टेनेंट ट्रैफ़िक को डिफ़ॉल्ट रूप से अस्वीकार करता है.
  • रीयल-टाइम ऑडिटिंग: पुष्टि करने के लिए टेस्ट सुइट को पूरी तरह से चलाएं, Linux कर्नेल लेवल पर रीयल-टाइम पैकेट ड्रॉप देखें, और Google Cloud Logging में सीधे तौर पर स्ट्रक्चर्ड पॉलिसी-ऐक्शन ऑडिट के बारे में क्वेरी करें

अगले चरण / ज़्यादा जानें

GKE नेटवर्किंग के बारे में ज़्यादा जानें