‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

אבטחת שער

Autopilot Standard

בדף הזה מוסבר איך לאבטח שער באמצעות תכונות אבטחה שונות:

מדיניות SSL כדי לוודא שהשער משתמש בפרוטוקולים ובאלגוריתמים המאובטחים הנדרשים
אישורים לאבטחת תנועה בין לקוח לשער ובין שער לקצוות עורפיים באמצעות TLS
מדיניות האבטחה של Google Cloud Armor להגנה על שירותים מפני התקפות DDoS
שרת proxy לאימות זהויות (IAP) כדי לספק שכבת אימות והרשאה לפני שמאפשרים גישה לשירות
כללי מדיניות הרשאה לאכיפת בקרת גישה מבוססת-זהות וארכיטקטורת אפס אמון בשכבת השער (Gateway)

כדי להעביר תנועת TLS מוצפנת ישירות לקצוות עורפיים בלי לסיים את ה-TLS או לנהל אישורים ב-Gateway, קראו את המאמר פריסת Gateway מסוג TLS passthrough.

למידע נוסף על מושגי אבטחה של Gateway, קראו את המאמר אבטחת Gateway.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

מפעילים את Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי להוריד את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא תומכות בהרצת הפקודות שבמסמך הזה.
הערה: אם ה-CLI של gcloud כבר מותקן, צריך להגדיר את המאפיין compute/region. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

הדרישות של GKE Gateway Controller

אפשר להשתמש ב-Gateway API רק באשכולות מותאמים ל-VPC.
אם אתם משתמשים ב-GatewayClasses אזוריים או חוצי-אזורים, אתם צריכים להפעיל רשת משנה של שרתי proxy בלבד.
התוסף HttpLoadBalancing צריך להיות מופעל באשכול.
אם אתם משתמשים ב-Istio, אתם צריכים לשדרג את Istio לאחת מהגרסאות הבאות:
- ‫1.15.2 ואילך
- ‫1.14.5 ואילך
- ‫1.13.9 ואילך.
אם אתם משתמשים ב-VPC משותף, בפרויקט המארח אתם צריכים להקצות את התפקיד Compute Network User לחשבון השירות של GKE בפרויקט השירות.
מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. אם צריך, יוצרים אשכול Autopilot.

הגבלות ומגבלות

בנוסף להגבלות של בקר GKE Gateway, המגבלות הבאות חלות באופן ספציפי על אבטחת Gateway:

בגרסה 1.28.4-gke.1083000 של GKE אין תמיכה בהגדרות TLS שמשתמשות באישור SSL או בCertificate Manager בשערים. כדי לעקוף את הבעיה בגרסה הזו של GKE, אפשר להשתמש בסוד של Kubernetes.
אי אפשר להשתמש בהערה networking.gke.io/certmap עם tls.certificateRefs באותו משאב Gateway. אם תפנו אל CertificateMap ב-Gateway, ‏ GKE יתייחס לזה כשגיאה.
ב-Certificate Manager יש תמיכה גם באישורים בניהול עצמי וגם באישורים בניהול Google. אישורים שמנוהלים על ידי Google תואמים לשערי API אזוריים ולשערי API גלובליים.
כשמשתמשים באישורי SSL בניהול Google, צריך ליצור את אישורי ה-SSL מחוץ ל-GKE לפני שמצרפים אותם לשער.
אי אפשר להשתמש באותו שירות כ-backend לשער אזורי ולשער גלובלי אם אתם מפנים למדיניות אבטחה של Google Cloud Armor לקצה העורפי ב-GCPBackendPolicy. במקרה כזה, צריך ליצור שני שירותים ושני כללי מדיניות נפרדים.
בקר השער לא תומך במשאב ManagedCertificate.
בקר ה-Gateway לא תומך בהערה networking.gke.io/managed-certificates.
אם מגדירים את Cloud CDN באמצעות GKE Gateway, אי אפשר להפעיל גם את IAP וגם את Cloud CDN באמצעות אותו Gateway, כולל נתיבים ספציפיים עם Cloud CDN. אם אתם צריכים להפעיל את Cloud CDN לנתיב שמשתמש במשאב GCPHTTPFilter, קודם אתם צריכים להסיר את כל המדיניות הקיימת של GCPBackendPolicy שמגדירה את IAP לשער הזה.
מכסת TrustConfig. במאמר מכסות ומגבלות של משאבים מוסבר מה הגודל הכולל של כל משאבי TrustConfig בכל מיקום.
יישור המיקום. משאב ה-TrustConfig שאליו מפנים חייב להיות באותו מיקום (גלובלי או אזור ספציפי) כמו השער שמשתמש בשירות.
אילוץ של מרחב שמות. המשאב BackendTLSPolicy ומשאב המטרה שלו צריכים להיות באותו מרחב שמות.
מעבר TLS. כשפורסים שער מעבר של TLS (השדה tls.mode מוגדר ל-Passthrough) עם משאבי TLSRoute, אל תצרפו אישורים או סודות של Kubernetes למאזין של השער. בנוסף, משאבי BackendTLSPolicy, כללי מדיניות SSL, כללי מדיניות האבטחה של Google Cloud Armor,‏ IAP ומסנני CORS לא חלים על תנועה שעוברת דרך TLS. מידע נוסף זמין במאמר פריסת שער מעבר של TLS.

במאמר יכולות של GatewayClass מפורטים השדות והיכולות של Gateway API שנתמכים במשאבי GatewayClass שזמינים ב-GKE.

אבטחת שער באמצעות סוד של Kubernetes

בדוגמה הזו, מגדירים שער באמצעות Kubernetes Secret.

אחסון אישור ב-Kubernetes Secret

אתם יכולים להשתמש באישור שהונפק ואומת על ידי רשות האישורים (CA) שלכם, או ליצור אישור עם חתימה עצמית. בשלבים הבאים נעשה שימוש באישור בחתימה עצמית.

יוצרים מפתח פרטי:
```
openssl genrsa -out PRIVATE_KEY_FILE 2048
```
מחליפים את PRIVATE_KEY_FILE בשם של קובץ המפתח הפרטי, למשל private-key.pem. מידע נוסף זמין במאמר בחירה או יצירה של מפתח פרטי.

יוצרים קובץ תצורה של Open SSL:

cat <<EOF >CONFIG_FILE
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
0.organizationName        = example
commonName                = store.example.com

[sans_list]
DNS.1                     = store.example.com
EOF

מחליפים את CONFIG_FILE בשם של קובץ התצורה החדש, למשל config-file.cnf.

יוצרים קובץ של בקשה לחתימה על אישור (CSR):
```
openssl req -new -key PRIVATE_KEY_FILE \
    -out CSR_FILE \
    -config CONFIG_FILE
```
מחליפים את CSR_FILE בשם של קובץ ה-CSR החדש, למשל cert.pem. מידע נוסף זמין במאמר יצירת CSR.

חותמים על ה-CSR:

openssl x509 -req \
    -signkey PRIVATE_KEY_FILE \
    -in CSR_FILE \
    -out CERTIFICATE_FILE \
    -extfile CONFIG_FILE \
    -extensions extension_requirements \
    -days 30

מחליפים את CERTIFICATE_FILE בנתיב ובשם של הקובץ שהפקודה יוצרת, למשל cert-file.pem. מידע נוסף זמין במאמר חתימה על ה-CSR.

יוצרים סוד TLS ב-Kubernetes באמצעות המפתח וקובץ האישור שיצרתם:
```
kubectl create secret tls store-example-com \
    --cert=CERTIFICATE_FILE \
    --key=PRIVATE_KEY_FILE
```
‫GKE שומר את האישור והמפתח כמשאב ב-Kubernetes שאפשר לצרף לשער.

יצירת Gateway ו-HTTPRoute

שומרים את המניפסט הבא בתור external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs: # Directly reference the Kubernetes Secret containing the TLS certificate and private key.
      - name: store-example-com # The name of the TLS secret.

המניפסט הזה מתאר שער עם המאפיינים הבאים:

‫gatewayClassName: gke-l7-global-external-managed: פריסה של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
‫protocol: HTTPS ו-port: 443: נדרשים כדי להפעיל את TLS.
‫tls: מפנה לסוד של Kubernetes שנוצר בשלב הקודם.

מחילים את המניפסט על האשכול:
```
kubectl apply -f external-gateway.yaml
```

שומרים את המניפסט הבא בתור store-external-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http # Link this route to the 'external-http' Gateway.
  hostnames:
  - "store.example.com" # Match traffic for this hostname.
  rules:
  - backendRefs: # Define where to forward the traffic.
    - name: store-v1
      port: 8080

המניפסט הזה מתאר HTTPRoute שתואם לתנועה אל store.example.com ושולח אותה לשירות store-v1.

מחילים את המניפסט על האשכול:
```
kubectl apply -f store-external-route.yaml
```

אימות השער

כדי לוודא שהשער פועל, שולחים בקשה דרך האינטרנט.

משיגים את כתובת ה-IP של השער:
```
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
```
הפלט אמור להיראות כך:
```
203.0.113.12
```
הפלט הזה הוא כתובת IP ציבורית, כלומר כל לקוח עם גישה לאינטרנט יכול להתחבר אליה.

נכנסים לדומיין של השער באמצעות curl:

curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v

מחליפים את מה שכתוב בשדות הבאים:

‫GATEWAY_IP_ADDRESS: כתובת ה-IP של מאזן העומסים של השער.
‫CERTIFICATE_FILE: קובץ האישור שיצרתם. אתם צריכים לשמור את הקובץ הזה במחשב שבו אתם משתמשים כדי להתחבר לשער. האישור נדרש כדי לאמת את השער, כי השער משתמש באישור עם חתימה עצמית.

האפשרות --resolve פותרת את שם הדומיין לכתובת ה-IP של השער, וזה נדרש כי ה-DNS לא מוגדר לדומיין הזה.

הפלט אמור להיראות כך:

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
# This block shows the certificate details presented by the Gateway.
# The value of the 'common name' field matches the requested hostname.
* Server certificate:
*  subject: O=example; CN=store.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: store.example.com (matched)
*  issuer: O=example; CN=store.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gw",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "store-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08"
  # Several lines of output omitted here.
}

הפלט הזה כולל לחיצת יד מוצלחת בפרוטוקול TLS, ואחריה תגובה מהאפליקציה. חיבור ה-TLS מסתיים בשער, והאפליקציה מגיבה ללקוח באופן מאובטח.

אבטחת שער באמצעות אישור SSL

בדוגמה הזו מגדירים שער עם אישור SSL בניהול Google.

יצירת אישור SSL

יוצרים משאב SslCertificate גלובלי בניהול Google:

gcloud compute ssl-certificates create store-example-com \
    --domains=store.example.com \
    --global

יצירת Gateway ו-HTTPRoute

שומרים את המניפסט הבא בתור external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate # Terminate TLS using your SSL certificate.
      options:
        networking.gke.io/pre-shared-certs: store-example-com # Specify the Google Cloud SSL certificate resource name.

המניפסט הזה מתאר שער עם המאפיינים הבאים:

‫gatewayClassName: gke-l7-global-external-managed: פריסה של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
‫protocol:HTTPS ו-port:443: נדרשים כדי להפעיל את TLS.
‫tls.mode:Terminate: מסיים את TLS באמצעות אישור ה-SSL שלכם.

מחילים את המניפסט על האשכול:
```
kubectl apply -f external-gateway.yaml
```

שומרים את המניפסט הבא של HTTPRoute בשם store-external-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

פורסים את ה-HTTPRoute באשכול:
```
kubectl apply -f store-external-route.yaml
```
יכול להיות שיעברו כמה דקות עד ש-GKE יפרוס את השער.

אימות השער

משיגים את כתובת ה-IP של השער:
```
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
```
הפלט אמור להיראות כך:
```
203.0.113.12
```
הפלט הזה הוא כתובת IP ציבורית, כלומר כל לקוח עם גישה לאינטרנט יכול להתחבר אליה.
מעדכנים רשומת A או רשומת AAAA כדי להפנות את הדומיין לכתובת ה-IP של השער.

השלב הזה נדרש רק אם אתם מגדירים אישור SSL בניהול Google. אם אתם מגדירים אישור בניהול עצמי, אתם יכולים לדלג על השלב הזה.

אחרי שמעדכנים את רשומות ה-DNS, יכול להיות שיעברו עד 10 דקות לפני שמאזן העומסים יתחיל להשתמש באישור שמנוהל על ידי Google.

כדי לוודא שהשער פועל, שולחים בקשה דרך האינטרנט באמצעות curl:

curl https://store.example.com -v

הפלט אמור להיראות כך:

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=store.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: store.example.com (matched)
*  issuer: O=example; CN=store.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gw",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "store-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08",
  "zone": "us-west1-a"
}

הפלט הזה כולל לחיצת יד מוצלחת בפרוטוקול TLS ותגובה מהאפליקציה. ה-TLS מסתיים ב-Gateway בצורה תקינה, והאפליקציה מגיבה ללקוח באופן מאובטח.

אבטחת שער באמצעות Certificate Manager

בדוגמה הזו מגדירים שער באמצעות Certificate Manager.

יצירת אישור

Global Gateway

כדי ליצור שער גלובלי, צריך להפנות למשאב של מפת אישורים שמכיל אישור אחד או יותר. צריך ליצור לפחות אישור אחד ולהוסיף אותו כרשומה במפת האישורים.

כדי ליצור אישור, קודם צריך ליצור מפתח פרטי וקובץ אישור.

יוצרים משאב של אישור על ידי טעינת האישור והמפתח בניהול עצמי:

gcloud certificate-manager certificates create store-example-com-cert \
    --certificate-file="cert.pem" \
    --private-key-file="PRIVATE_KEY_FILE"

יוצרים CertificateMap:

gcloud certificate-manager maps create store-example-com-map

יוצרים CertificateMapEntry שמקצה את האישור ל-CertificateMap:

gcloud certificate-manager maps entries create store-example-com-map-entry \
    --map=store-example-com-map \
    --hostname=store.example.com \
    --certificates=store-example-com-cert

שער אזורי

בשער אזורי, יוצרים אישור שיצוין ישירות כשיוצרים את השער. בניגוד לשער גלובלי, לא צריך ליצור CertificateMap שמוקצים לו אישורים.

יוצרים מפתח פרטי וקובץ אישור.
יוצרים משאב Certificate על ידי העלאת קובץ האישור והמפתח:

gcloud certificate-manager certificates create "CERTIFICATE_NAME" \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE" \
    --location="REGION"

מחליפים את מה שכתוב בשדות הבאים:

‫CERTIFICATE_NAME: שם האישור, לדוגמה store-example-com-cert.
‫CERTIFICATE_FILE: השם של קובץ האישור, לדוגמה cert.pem.
‫PRIVATE_KEY_FILE: השם של קובץ המפתח הפרטי, למשל private-key.pem. מידע נוסף זמין במאמר בחירה או יצירה של מפתח פרטי.
‫REGION: שם האזור שבו מגדירים את השער, לדוגמה us-central1.

יצירת Gateway ו-HTTPRoute

Global Gateway

כדי ליצור שער גלובלי:

שומרים את המניפסט הבא בתור cert-map-gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
  # No TLS section is included here because TLS is handled by the certmap annotation.
```
המניפסט הזה מתאר שער עם המאפיינים הבאים:
- ‫gatewayClassName: gke-l7-global-external-managed: פריסה של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
- ‫protocol: HTTPS ו-port: 443: נדרשים כדי להפעיל את TLS.
אין קטע TLS כי TLS מוגדר באמצעות Certificate Manager באמצעות ההערה networking.gke.io/certmap.
מחילים את המניפסט על האשכול:
```
kubectl apply -f cert-map-gateway.yaml
```
יכול להיות שיעברו כמה דקות עד ש-GKE יפרוס את השער.

כדי ליצור HTTPRoute, שומרים את המניפסט הבא בתור cert-map-http-route.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo
  namespace: default
spec:
  parentRefs:
  - name: external-http
  hostnames:
  - foo.example.com
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: foo-v1
      port: 8080

מחילים את המניפסט על האשכול:
```
kubectl apply -f cert-map-http-route.yaml
```

שער אזורי

כשיוצרים שער אזורי, אפשר לציין אישורים שמנוהלים על ידי Certificate Manager ואישורים שמנוהלים על ידי Compute Engine.

כדי ליצור שער חיצוני אזורי, שומרים את המניפסט הבא בתור external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: gateway
     namespace: corp
   spec:
     gatewayClassName: gke-l7-regional-external-managed
     listeners:
     - name: gateway-pre-shared-certmap
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate # TLS is terminated at the Gateway.
         options: # Specifies a comma-separated list of Certificate Manager certificates to use for TLS termination.
           networking.gke.io/cert-manager-certs: store-example-com-cert1, store-example-com-cert2 # These certificates are directly managed by Certificate Manager.
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All

המניפסט הזה מתאר שער עם המאפיינים הבאים:

‫gatewayClassName: gke-l7-regional-external-managed: פריסה של מאזן עומסים חיצוני אזורי של אפליקציות (ALB).
‫protocol: HTTPS ו-port: 443: נדרשים כדי להפעיל את TLS.
options:
- ‫networking.gke.io/cert-manager-certs : אישורים שמנוהלים על ידי Certificate Manager.

כדי ליצור שער פנימי אזורי, בדוגמה הקודמת משנים את הערך של gatewayClassName ל-gke-l7-rilb. כך פורסים מאזן עומסים פנימי של אפליקציות (ALB).

מחילים את המניפסט על האשכול:
```
kubectl apply -f external-gateway.yaml
```

כדי ליצור HTTPRoute, שומרים את המניפסט הבא בתור store-external-route.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

המניפסט הזה מתאר HTTPRoute שתואם לתנועה של store.example.com ומעביר את התנועה לשירות store-v1.

מחילים את המניפסט על האשכול:
```
kubectl apply -f store-external-route.yaml
```

אימות השער

משיגים את כתובת ה-IP של השער:
```
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
```
הפלט אמור להיראות כך:
```
203.0.113.12
```
הפלט הזה הוא כתובת IP ציבורית, כלומר כל לקוח עם גישה לאינטרנט יכול להתחבר אליה.
מעדכנים רשומת A או רשומת AAAA כדי להפנות את הדומיין לכתובת ה-IP של השער.

השלב הזה נדרש רק אם אתם מגדירים אישור SSL בניהול Google. אם אתם מגדירים אישור בניהול עצמי, אתם יכולים לדלג על השלב הזה.

אחרי שמעדכנים את רשומות ה-DNS, יכול להיות שיעברו עד 10 דקות לפני שמאזן העומסים יתחיל להשתמש באישור שמנוהל על ידי Google.

נכנסים לדומיין של השער באמצעות curl:

curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v

מחליפים את מה שכתוב בשדות הבאים:

‫GATEWAY_IP_ADDRESS: כתובת ה-IP של מאזן העומסים של השער.
‫CERTIFICATE_FILE: קובץ האישור שיצרתם. אתם צריכים לשמור את הקובץ הזה במחשב שבו אתם משתמשים כדי להתחבר לשער. האישור נדרש כדי לאמת את השער, כי השער משתמש באישור עם חתימה עצמית.

הפלט אמור להיראות כך:

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=store.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: store.example.com (matched)
*  issuer: O=example; CN=store.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gw",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "store-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08",
  "zone": "us-west1-a"
}

הגדרת mTLS בקצה הקדמי של שער

אתם יכולים להגדיר אימות של אישור לקוח, שנקרא גם mTLS של ממשק קצה (frontend), בשביל GKE Gateway.

‫mTLS של ממשק קצה (frontend) נתמך ב-GatewayClasses הבאים:

gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc

‫mTLS בממשק הקצה מאפשר לשער לאמת את האישורים שהלקוחות מציגים, והוא תקף למאזיני HTTPS שמשתמשים במצב Terminate.

אפשר להגדיר mTLS לקצה הקדמי באחת מהדרכים הבאות:

שימוש בהגדרות של Gateway API (מומלץ).
שימוש בהערת TrustConfig בניהול עצמי בשער (מתקדם).

הגדרת mTLS בקצה הקדמי באמצעות הגדרת Gateway API (מומלץ)

השימוש ב-Gateway API הוא הדרך המומלצת להגדיר אימות של אישורי לקוח. בשיטה הזו, מקורות האמון נשמרים ב-ConfigMap של Kubernetes, וה-ConfigMap הזה מאוזכר במפרט של השער.

ליצור מקורות מהימנים.

מקורות מהימנים קובעים ומאמתים את שורש האמון של אישורי הלקוח שמוצגים למאזן העומסים. ‫GKE Gateway תומך במקורות מהימנים שמבוססים על אישורי בסיס.

כדי ליצור אישורים, קראו את המאמר יצירת אישורי הבסיס והאישורים המתווכים.
יוצרים ConfigMap.

אחסון מקורות האמון ב-ConfigMap של Kubernetes. כל מפתח ב-ConfigMap חייב להכיל בדיוק אישור CA אחד בקידוד PEM בפורמט x509 תקין. צריך ליצור את ConfigMap באותו מרחב שמות של משאב השער, אלא אם משתמשים ב-ReferenceGrant. כדי להפנות ל-ConfigMap במרחב שמות אחר, אפשר לעיין במאמר ReferenceGrant.

מציבים את נתוני האישור מתחת למפתח ca.crt:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-cert
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    <PEM_DATA>
    -----END CERTIFICATE-----
```
הערה: אפשר להפנות לעד שמונה משאבי ConfigMap לכל הגדרה (בהגדרת ברירת המחדל או בהגדרה לכל יציאה). כשמשתמשים ב-ConfigMap, יש תמיכה רק באישורי בסיס. כדי להשתמש באישורים מותרים או באישורי ביניים, צריך להשתמש במשאב TrustConfig בניהול עצמי.

כדי ליצור ConfigMap עם האישורים, מריצים את הפקודה הבאה:
```
kubectl create configmap my-config \
    --from-file=ca.crt=ROOT_CERT_PATH
```
מחליפים את הערך של ROOT_CERT_PATH בנתיב לקובץ האישור. ‫ConfigMap יכול להכיל רק אישור אחד.

מגדירים את השער.

מצרפים את ה-ConfigMap לשער על ידי הוספת קטע tls שמכיל את השדה frontend.default.validation למפרט של השער. ההגדרה default נדרשת והיא חלה על כל מאזיני ה-HTTPS שמשתמשים במצב Terminate, אלא אם מציינים הגדרה לכל יציאה. הדוגמה הבאה מראה הגדרת Gateway מקצה לקצה, שכוללת גם אישור שרת (באמצעות ההערה certmap) וגם אימות של אישור לקוח (באמצעות השדה tls.frontend.default.validation):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: my-config
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # No certificateRefs needed when using the certmap annotation

שינוי ההגדרות של כל יציאה.

אפשר גם לציין מקורות מהימנים ייחודיים ליציאות ספציפיות. הגדרה לכל יציאה מבטלת את הגדרת ברירת המחדל לכל המאזינים שהוגדרו ליציאה הזו.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-port-override
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: global-ca-config
      perPort:
      - port: 8443
        tls:
          validation:
            caCertificateRefs:
            - kind: ConfigMap
              group: ""
              name: port-specific-ca-config
  listeners:
  - name: https-default
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
  - name: https-override
    protocol: HTTPS
    port: 8443
    tls:
      mode: Terminate

אופציונלי: מגדירים את מצב האימות של הלקוח.

כברירת מחדל, שערי GKE אוכפים אימות קפדני של אישורי לקוח (AllowValidOnly). כדי לאפשר אישורי לקוח לא חוקיים או חסרים, בהגדרות של frontend.default.validation, מגדירים את הערך של המפתח mode ל-AllowInsecureFallback:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/certmap: store-example-com-map # Add this annotation
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: my-config
          mode: AllowInsecureFallback
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # No certificateRefs needed when using the certmap annotation

שימוש ב-TrustConfig בניהול עצמי (מתקדם)

לחלופין, אפשר להגדיר אימות של אישור לקוח על ידי הוספת הערה ל-Gateway באמצעות משאב TrustConfig. השיטה הזו מתאימה אם אתם צריכים גמישות נוספת או אם ההגדרות שלכם חורגות מהמגבלות הרגילות של Gateway API. השיטה הזו לא יכולה לפעול במקביל לשיטת ההגדרה של Gateway API, והיא חלה על כל מאזיני ה-HTTPS ב-Gateway (אין תמיכה בשינויים לכל יציאה).

יוצרים משאב TrustConfig. להוראות, ראו יצירת משאב של הגדרת אמון.

כשיוצרים את המשאב TrustConfig, צריך לציין את הערך global לשערים גלובליים (gke-l7-global-external-managed) ולכל השערים בכמה אשכולות (gke-l7-global-external-managed-mc,‏ gke-l7-regional-external-managed-mc,‏ gke-l7-cross-regional-internal-managed-mc ו-gke-l7-rilb-mc), או את האזור המתאים (לדוגמה, us-central1) לשערים אזוריים (gke-l7-regional-external-managed ו-gke-l7-rilb).

מצרפים את TrustConfig ל-Gateway באמצעות ההערה networking.gke.io/frontend-trust-config.

בדוגמה הבאה מוצגת הגדרת Gateway מקצה לקצה, שכוללת גם אישור שרת (באמצעות ההערה certmap) וגם אימות אישור לקוח (באמצעות ההערה TrustConfig):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/frontend-trust-config: my-trust-config
    networking.gke.io/certmap: store-example-com-map # Add this annotation
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # Remove certificateRefs and replace with the comment
      # No certificateRefs needed when using the certmap annotation

אופציונלי: מגדירים את מצב האימות של הלקוח.

כברירת מחדל, שערי GKE אוכפים אימות קפדני של אישורי לקוח (REJECT_INVALID). כדי לאפשר אישורי לקוח חסרים או לא תקינים, מגדירים את ההערה networking.gke.io/allow-invalid-or-missing-client-cert לערך true.

הגדרת TLS לקצה העורפי של שער

‫Backend TLS מאפשר למאזן העומסים של GKE Gateway לאמת את הזהות של הקצוות העורפיים שאליהם הוא מתחבר. פרוטוקול TLS לקצה העורפי מוסיף שלב אימות מפורש במהלך לחיצת היד בפרוטוקול TLS בין השער לבין ה-Pod של הקצה העורפי. השער פועל כלקוח TLS, ומאמת את האישור של שרת בק-אנד מול קבוצה של רשויות אישורים (CA) מהימנות שאתם מגדירים. האימות הזה מתבצע כשנוצר חיבור חדש, כדי לוודא שהשער מתקשר רק עם שרתי backend מהימנים ולשפר את האבטחה הכוללת.

אתם יכולים להגדיר אימות TLS לקצה העורפי באמצעות משאב BackendTLSPolicy שמצורף ל-Service, ל-InferencePool, ל-ServiceImport או ל-GCPInferencePoolImport. המדיניות BackendTLSPolicy צריכה להיות באותו מרחב שמות כמו משאב המטרה.

יש תמיכה ב-TLS לקצה העורפי ב-GatewayClasses הבאים:

gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

הגדרת mTLS בבק-אנד לשער

‫Backend mutual TLS (mTLS)‎ היא תכונה שמבוססת על backend authenticated TLS. למרות ש-TLS מאומת בבק-אנד מאמת את הזהות של Pods בבק-אנד למאזן העומסים, mTLS בבק-אנד מאפשר למאזן העומסים של GKE Gateway גם לאמת את הזהות שלו ל-Pods בבק-אנד על ידי הצגת אישור לקוח. כחלק מהגדרת mTLS בבק-אנד, צריך להגדיר TLS מאומת בבק-אנד.

ב-GKE Gateway, מגדירים mTLS בבק-אנד באמצעות השדה הסטנדרטי spec.tls.backend.clientCertificateRef ב-Gateway API.

יש תמיכה ב-mTLS בבק-אנד ב-GatewayClasses הבאים:

gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc

כדי להגדיר mTLS בבק-אנד:

מאחסנים את אישור הלקוח ואת המפתח הפרטי ב-Secret רגיל של Kubernetes.
מפנים לסוד של אישור הלקוח במפרט של משאב השער.
מגדירים TLS מאומת לקצה העורפי באמצעות BackendTLSPolicy שמטרגט את השירות.

שלב 1: אחסון פרטי הכניסה של הלקוח

לפני שאתם שומרים את פרטי הכניסה של הלקוח, ודאו שהאישור עומד בדרישות האישור.

כדי לאחסן את אישור הלקוח ואת המפתח הפרטי בסוד TLS רגיל של Kubernetes באותו מרחב שמות כמו המשאב של השער, מריצים את הפקודה הבאה:

kubectl create secret tls gateway-client-identity \
    --cert=PATH_TO_CERT_FILE \
    --key=PATH_TO_KEY_FILE \
    --namespace=default

מחליפים את הערכים הבאים:

‫PATH_TO_CERT_FILE: הנתיב לקובץ אישור הלקוח בפורמט PEM.
‫PATH_TO_KEY_FILE: הנתיב לקובץ המפתח הפרטי בפורמט PEM.

שלב 2: הפניה לפרטי הכניסה של הלקוח בשער

כדי להפנות לסוד של אישור הלקוח בבלוק spec.tls.backend של משאב השער, שומרים את המניפסט הבא בתור my-gateway.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    backend:
      clientCertificateRef:
        group: "" # empty group resolves to Core API
        kind: Secret
        name: gateway-client-identity
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-gateway.yaml
```

שלב 3: החלת ה-BackendTLSPolicy

כדי לאמת את הזהות של שרת בק-אנד, צריך להחיל מדיניות BackendTLSPolicy שמטרגטת את השירות שאליו מפנה ה-HTTPRoute.

במאמר הגדרת TLS לקצה העורפי של שער מפורטות הוראות ומניפסטים להגדרת TLS מאומת לקצה העורפי.

שימוש ב-ConfigMap של Kubernetes (רגיל)

בשיטה הזו, אתם מספקים את אישור ה-CA ישירות ב-ConfigMap של Kubernetes.

יוצרים משאב ConfigMap שמכיל את אישורי ה-CA בקידוד PEM. למידע נוסף, קראו את הדרישות לאישורים. כל ConfigMap חייב להכיל רק אישור CA אחד. צריך ליצור את ה-ConfigMap הזה באותו מרחב שמות של המשאב BackendTLSPolicy. ‫BackendTLSPolicy לא תומך בהפניות בין מרחבי שמות למשאבי ConfigMap.

הערה: מדיניות BackendTLSPolicy אחת תומכת בהפניה לעד שמונה משאבי ConfigMap בשדה caCertificateRefs.

צריך להזין את נתוני האישור במפתח ca.crt:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-backend-ca
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    PEM_DATA
    -----END CERTIFICATE-----
```
מחליפים את PEM_DATA בתוכן של אישור ה-CA בפורמט PEM ובקידוד Base64.

מטרגטים Service,‏ InferencePool,‏ ServiceImport או GCPInferencePoolImport באמצעות BackendTLSPolicy שמפנה ל-ConfigMap:

שירות

במניפסט הבא מוצגת מדיניות BackendTLSPolicy שמטרגטת שירות:

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: secure-backend-policy
spec:
  targetRefs:
  - group: "" # empty group means Core API.
    kind: Service
    name: my-service-name
  validation:
    hostname: "backend.example.com"
    caCertificateRefs:
    - group: "" # empty group means Core API.
      kind: ConfigMap
      name: my-backend-ca

InferencePool

המניפסט הבא מציג BackendTLSPolicy שמטרגט InferencePool:

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: secure-backend-policy-inferencepool
spec:
  targetRefs:
  - group: "inference.networking.k8s.io" # For InferencePool
    kind: InferencePool
    name: my-inference-pool
  validation:
    hostname: "backend.example.com"
    caCertificateRefs:
    - group: "" # empty group means Core API.
      kind: ConfigMap
      name: my-backend-ca

ServiceImport

במניפסט הבא מוצגת מדיניות BackendTLSPolicy שמטרגטת ServiceImport:

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: secure-backend-policy-serviceimport
spec:
  targetRefs:
  - group: "net.gke.io" # For ServiceImport
    kind: ServiceImport
    name: my-service-import
  validation:
    hostname: "backend.example.com"
    caCertificateRefs:
    - group: "" # empty group means Core API.
      kind: ConfigMap
      name: my-backend-ca

GCPInferencePoolImport

במניפסט הבא מוצגת מדיניות BackendTLSPolicy שמטרגטת GCPInferencePoolImport:

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: secure-backend-policy-gcpinferencepoolimport
spec:
  targetRefs:
  - group: "networking.gke.io" # For GCPInferencePoolImport
    kind: GCPInferencePoolImport
    name: my-gcp-inference-pool-import
  validation:
    hostname: "backend.example.com"
    caCertificateRefs:
    - group: "" # empty group means Core API.
      kind: ConfigMap
      name: my-backend-ca

שימוש ב-TrustConfig בניהול עצמי (מתקדם)

בשיטה הזו אתם יכולים להפנות למשאב TrustConfig שאתם מנהלים באופן עצמאי ב-Certificate Manager ב- Google Cloud.

יוצרים משאב TrustConfig ב-Certificate Manager. צריך ליצור את TrustConfig באותו פרויקט ובאותו מיקום שבהם נמצא השער.
- בשערי כניסה גלובליים או עם כמה אשכולות (כולל שערי כניסה אזוריים עם כמה אשכולות) ובשערי כניסה חוצי-אזורים, צריך להשתמש במיקום global.
- בשערי אשכול יחיד אזוריים, משתמשים באותו אזור של השער.
- אם אתם משתמשים בשירות בכמה שערים במיקומים שונים, אתם צריכים ליצור משאב TrustConfig עם אותו שם בכל אחד מהמיקומים האלה.

מטרגטים שירות באמצעות BackendTLSPolicy שמפנה למשאב TrustConfig החיצוני דרך השדה options:

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: secure-backend-policy
spec:
  targetRefs:
  - group: "" # empty group means Core API.
    kind: Service
    name: my-service-name
  validation:
    wellKnownCACertificates: "System"
    hostname: "backend.example.com"
    options:
      networking.gke.io/backend-trust-config: "my-trust-config-name"

הפניה לשדה BackendTLSPolicy

בטבלה הבאה מתוארים השדות העיקריים במשאב BackendTLSPolicy:

שדה	תיאור
`targetRefs`	משאבי הקצה העורפי שהמדיניות הזו חלה עליהם. תומך ב-Service (`group: ""`), ב-InferencePool (`group: "inference.networking.k8s.io"`), ב-ServiceImport (`group: "net.gke.io"`) או ב-GCPInferencePoolImport (`group: "networking.gke.io"`). הערה: ב-GatewayClasses מסוג `gke-l7-global-external-managed` ו-`gke-l7-global-external-managed-mc`, יש תמיכה רק בקצוות עורפיים מסוג Service ו-ServiceImport.
`validation.hostname`	שם המארח (SNI) שבו משתמש השער במהלך לחיצת היד בפרוטוקול TLS עם ה-pods לקצה העורפי.
`validation.subjectAltNames`	זה שינוי אופציונלי. מגדירה שם חלופי אחד או יותר של בעלים (subject) (SAN) לאימות מול האישור של הקצה העורפי. תמיכה ב-`Hostname` וב-`URI` (כמו מזהי SPIFFE).
`validation.caCertificateRefs`	שיטה רגילה. מפנה לרשימה של משאבי ConfigMap (עד שמונה) באותו מרחב שמות. כל ConfigMap חייב להכיל אישור CA יחיד בקידוד PEM במפתח `ca.crt`. אין תמיכה בהפניות בין מרחבי שמות.
`validation.wellKnownCACertificates`	שיטה מתקדמת. כשמשתמשים ב-TrustConfig בניהול עצמי, מגדירים את הערך `System`.
`options`	מפה של אפשרויות ספציפיות ל-GKE. משתמשים בהגדרה `networking.gke.io/backend-trust-config` כדי להפנות למשאב TrustConfig חיצוני.

אימות הגדרת ה-TLS של ה-backend

אחרי שמחילים את BackendTLSPolicy, בודקים את סטטוס המדיניות כדי לוודא שבקר ה-Gateway קיבל את ההגדרה:

kubectl describe backendtlspolicy POLICY_NAME

מחליפים את POLICY_NAME בשם המדיניות.

המדיניות מוחלת בהצלחה אם היא מכילה את התנאים Accepted ו-ResolvedRefs עם Status: "True" בקטע Status.Ancestors:

Status:
  Ancestors:
  - Ancestor Ref:
      Group: gateway.networking.k8s.io
      Kind: Gateway
      Name: my-gateway-name
      Namespace: default
    Conditions:
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: Accepted
      Status: "True"
      Type: Accepted
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: ResolvedRefs
      Status: "True"
      Type: ResolvedRefs
    Controller Name: networking.gke.io/gateway

אם הערך של Status הוא False באחד מהתנאים האלה, סימן שהמדיניות לא הוחלה. אפשר לעיין בשדות Reason ו-Message כדי לקבל פרטים נוספים. שגיאות נפוצות כוללות הפניה ל-ConfigMap ב-caCertificateRefs שלא קיים או שחסר בו המפתח ca.crt.

הסטטוס הזה מאשר שהשער אימת בהצלחה את המדיניות והחיל את הגדרות ה-TLS על הקצה העורפי של שירות היעד או InferencePool. המשאב BackendTLSPolicy צריך להיות באותו מרחב שמות כמו משאב היעד.

אבטחת התנועה ממאזן העומסים לאפליקציה באמצעות TLS

אפשר להצפין את התנועה ממאזן העומסים לפודים של הקצה העורפי באמצעות השדה ports[].appProtocol. השדות הנתמכים של appProtocol הם: HTTP,‏ HTTPS,‏ HTTP2 ו-kubernetes.io/h2c.

המניפסט הבא מתאר שירות שמציין שמאזן העומסים חייב להשתמש בתעבורת נתונים מסוג HTTPS כדי לתקשר עם Pods בקצה העורפי:

apiVersion: v1
kind: Service
metadata:
  name: store-v2
spec:
  selector:
    app: store
    version: v2
  ports:
  - port: 8080
    targetPort: 8080
    appProtocol: HTTPS

‫GKE Gateway Controller לא מנהל את האישור שמשמש את Pods לקצה העורפי. באחריותכם לוודא שהאישור שמשמש את Pods לקצה העורפי תקף.

אבטחת התנועה מהלקוח למאזן העומסים באמצעות כללי מדיניות SSL

כשהאפליקציות שלכם חשופות דרך שער חיצוני שמשתמש ב-HTTPS, חשוב להשתמש בפרוטוקולים העדכניים ביותר או לציין את הגרסה המינימלית של SSL או TLS. אתם יכולים לאבטח את התנועה מהלקוח למאזן העומסים באמצעות כללי מדיניות SSL.

במאמר הגדרת כללי מדיניות SSL לאבטחת התנועה מהלקוח למאזן העומסים מוסבר איך ליצור כללי מדיניות SSL שאפשר לצרף לשער.

הגנה על הקצה העורפי באמצעות Google Cloud Armor

כללי מדיניות האבטחה של Google Cloud Armor עוזרים להגן על האפליקציות שמוגדר בהן איזון עומסים מפני התקפות מבוססות-אינטרנט. אחרי שמגדירים מדיניות אבטחה של Google Cloud Armor, אפשר להפנות אליה ב-GCPBackendPolicy שמוחל על שירותי Kubernetes.

כדי להגדיר את כללי המדיניות של Google Cloud Armor באמצעות Gateway, קראו את המאמר הגדרת מדיניות האבטחה של Google Cloud Armor כדי לאבטח את שירותי הקצה העורפי.

אימות בקשות לקצוות העורפיים באמצעות שרת proxy לאימות זהויות (IAP)

שרת proxy לאימות זהויות (IAP) עוזר להגן על הקצה העורפי מפני תנועה לא רצויה, על ידי אימות לקוחות ששולחים בקשות לאפליקציות ואכיפת הרשאת תנועה שמבוססת על תפקידים. אחרי שמפעילים את שרת ה-Proxy לאימות זהויות (IAP) ב-GKE, אפשר להפנות לפרטי הכניסה ל-OAuth ב-GCPBackendPolicy שמוחל על שירותי Kubernetes.

כדי להגדיר את שרת ה-Proxy לאימות זהויות (IAP) עם Gateway, קראו את המאמר הגדרת שרת Proxy לאימות זהויות (IAP).

הגדרת שיתוף משאבים ממקורות שונים (CORS)

שיתוף משאבים בין מקורות (CORS) הוא מנגנון אבטחה שעוזר לאפליקציות אינטרנט שפועלות במקור (דומיין) אחד לגשת בצורה מאובטחת למשאבים שמתארחים במקור אחר. אפשר להגדיר מדיניות CORS ישירות במשאבי HTTPRoute באמצעות המסנן CORS. כשמגדירים את מסנן ה-CORS, ‏GKE Gateway מעביר את התגובה לבקשות קדם-הפעלה (OPTIONS) ואת ההוספה של כותרות תגובה של CORS מקוד האפליקציה.

מידע נוסף על הגדרת מסנן CORS והשדות הנתמכים זמין במאמר הגדרת שיתוף משאבים ממקורות שונים (CORS).

אכיפת בקרת גישה באמצעות מדיניות הרשאה

אתם יכולים לאכוף בקרת גישה פרטנית שמבוססת על זהות בתנועה שנכנסת לשער באמצעות כללי מדיניות הרשאה (GCPAuthzPolicy). המדיניות הזו מאפשרת לכם להגדיר כללים שALLOW או DENY בקשות על סמך זהות המקור (כמו השם החלופי של הבעלים או השם הנפוץ של אישור הלקוח), נתיב היעד או כותרות HTTP ספציפיות.

בתרחישי אבטחה מתקדמים, אתם יכולים להקצות את ההחלטות לגבי הרשאות לשירותים חיצוניים או למנועים של צד שלישי (כמו חומת אש ליישומי אינטרנט בהתאמה אישית) באמצעות תוסף שמפנה לבדיקת הרשאות (GCPAuthzExtension).

הגדרת מדיניות הרשאה של `ALLOW`

בדוגמה הבאה מתוארת מדיניות הרשאה שחלה על שער במרחב השמות default. המדיניות מגבילה את הגישה בכך שהיא מאפשרת רק בקשות לנתיבים /home ו-/public, ודוחה באופן משתמע את הגישה לכל שאר הנתיבים.

שומרים את המניפסט הבא ב-allow-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-paths
  namespace: default
spec:
  enforcementLevel: L7
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: "GATEWAY_NAME"
  action: ALLOW
  rules:
  - to:
      operations:
      - paths:
        - type: Exact
          value: "/home"
        - type: Exact
          value: "/public"

מחליפים את GATEWAY_NAME בשם של השער.

מחילים את המניפסט:
```
kubectl apply -f allow-policy.yaml
```

הגדרת מדיניות הרשאה של `DENY`

בדוגמה הבאה מתוארת מדיניות הרשאה שחלה על Gateway במרחב השמות default. המדיניות דוחה באופן מפורש את כל הבקשות לנתיב /private, ומאפשרת גישה לכל שאר הנתיבים כברירת מחדל.

שומרים את המניפסט הבא ב-deny-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-path
  namespace: default
spec:
  enforcementLevel: L7
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: "GATEWAY_NAME"
  action: DENY
  rules:
  - to:
      operations:
      - paths:
        - type: Exact
          value: "/private"

מחליפים את GATEWAY_NAME בשם של השער.

מחילים את המניפסט:
```
kubectl apply -f deny-policy.yaml
```

אבטחת שער קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

לפני שמתחילים

הדרישות של GKE Gateway Controller

הגבלות ומגבלות

אבטחת שער באמצעות סוד של Kubernetes

אחסון אישור ב-Kubernetes Secret

יצירת Gateway ו-HTTPRoute

אימות השער

אבטחת שער באמצעות אישור SSL

יצירת אישור SSL

יצירת Gateway ו-HTTPRoute

אימות השער

אבטחת שער באמצעות Certificate Manager

יצירת אישור

Global Gateway

שער אזורי

יצירת Gateway ו-HTTPRoute

Global Gateway

שער אזורי

אימות השער

הגדרת mTLS בקצה הקדמי של שער

הגדרת mTLS בקצה הקדמי באמצעות הגדרת Gateway API (מומלץ)

שימוש ב-TrustConfig בניהול עצמי (מתקדם)

הגדרת TLS לקצה העורפי של שער

הגדרת mTLS בבק-אנד לשער

שלב 1: אחסון פרטי הכניסה של הלקוח

שלב 2: הפניה לפרטי הכניסה של הלקוח בשער

שלב 3: החלת ה-BackendTLSPolicy

שימוש ב-ConfigMap של Kubernetes (רגיל)

שירות

InferencePool

ServiceImport

GCPInferencePoolImport

שימוש ב-TrustConfig בניהול עצמי (מתקדם)

הפניה לשדה BackendTLSPolicy

אימות הגדרת ה-TLS של ה-backend

אבטחת התנועה ממאזן העומסים לאפליקציה באמצעות TLS

אבטחת התנועה מהלקוח למאזן העומסים באמצעות כללי מדיניות SSL

הגנה על הקצה העורפי באמצעות Google Cloud Armor

אימות בקשות לקצוות העורפיים באמצעות שרת proxy לאימות זהויות (IAP)

הגדרת שיתוף משאבים ממקורות שונים (CORS)

אכיפת בקרת גישה באמצעות מדיניות הרשאה

הגדרת מדיניות הרשאה של ALLOW

הגדרת מדיניות הרשאה של DENY

המאמרים הבאים

אבטחת שער

הגדרת מדיניות הרשאה של `ALLOW`

הגדרת מדיניות הרשאה של `DENY`