אבטחת שער

טייס אוטומטי רגילה

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

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

מידע נוסף על אבטחת שערים זמין במאמר אבטחת שערים.

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

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

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

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-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-native.
אם אתם משתמשים ב-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:

גרסה GKE 1.28.4-gke.1083000 לא תומכת בהגדרות TLS באמצעות אישור SSL או Certificate Manager ב-Gateways. כפתרון זמני לגרסת GKE הזו, אפשר להשתמש בסוד של Kubernetes.
אי אפשר להשתמש בהערה networking.gke.io/certmap עם tls.certificateRefs באותו משאב של שער. אם מפנים אל CertificateMap ב-Gateway, ‏ GKE יתייחס לכך כשגיאה.
Certificate Manager תומך באישורים בניהול עצמי ובאישורים בניהול Google. אישורים שמנוהלים על ידי Google תואמים לשערי אזוריים ולשערים גלובליים.
כשמשתמשים באישורי SSL שמנוהלים על ידי Google, צריך ליצור את אישורי ה-SSL מחוץ ל-GKE לפני שמצרפים אותם ל-Gateway.
אי אפשר להשתמש באותו שירות כקצה עורפי לשער אזורי ולשער גלובלי אם מפנים אל מדיניות אבטחה של קצה עורפי ב-Google Cloud Armor ב-GCPBackendPolicy. כדי להשתמש בתרחיש הזה, צריך ליצור שני שירותים ושני כללי מדיניות נפרדים.
בקר השער לא תומך במשאב ManagedCertificate.
בבקר של שער הכניסה אין תמיכה בהערה networking.gke.io/managed-certificates.

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

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

בדוגמה הזו, מגדירים Gateway באמצעות 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 Secret שנוצר בשלב הקודם.

מחילים את המניפסט על האשכול:
```
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: קובץ האישור שיצרתם. צריך לשמור את הקובץ הזה במחשב שבו משתמשים כדי להתחבר לשער. האישור נדרש כדי לאמת את ה-Gateway כי הוא משתמש באישור עם חתימה עצמית.

האפשרות --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

יצירת שער ו-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 יפרוס את ה-Gateway.

אימות השער

קבלת כתובת ה-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 מסתיים בשער בצורה תקינה והאפליקציה מגיבה ללקוח בצורה מאובטחת.

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

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

יצירת `Certificate`

Global Gateway

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

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

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

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

שער אזורי

בשביל שער אזורי, יוצרים Certificate שיצוין ישירות כשיוצרים את השער. בניגוד לשער גלובלי, לא צריך ליצור 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.

יצירת שער ו-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 יפרוס את ה-Gateway.

כדי ליצור 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: קובץ האישור שיצרתם. צריך לשמור את הקובץ הזה במחשב שבו משתמשים כדי להתחבר לשער. האישור נדרש כדי לאמת את ה-Gateway כי הוא משתמש באישור עם חתימה עצמית.

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

...
* 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

אתם יכולים להצפין את התנועה ממאזן העומסים אל ה-Pods של הבק-אנד באמצעות השדה 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

מאזן העומסים לא מאמת את האישור שמשמש את ה-Pods של ה-Backend. באחריותכם לוודא שהאישור שבו נעשה שימוש ב-Pods של הקצה העורפי תקף.

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

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

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

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

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

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

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

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

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

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

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

דרישות של GKE Gateway controller

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

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

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

יצירת שער ו-HTTPRoute

אימות השער

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

יצירת אישור SSL

יצירת שער ו-HTTPRoute

אימות השער

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

יצירת Certificate

Global Gateway

שער אזורי

יצירת שער ו-HTTPRoute

Global Gateway

שער אזורי

אימות השער

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

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

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

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

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

אבטחת שער

יצירת `Certificate`