סקירה כללית של היתרונות המרכזיים

Service Extensions מאפשרים לכם להשתמש ב-callout משרתי Proxy ברשת. רוב מאזני העומסים של האפליקציות תומכים בנכסי היתרונות המרכזיים. Secure Web Proxy (בגרסת Preview) תומך גם בתוספי יתרונות מרכזיים.

זרימת נתונים של יתרונות מרכזיים

שרת proxy לרשת מתקשר עם callout באמצעות אחד מפרוטוקולי Envoy gRPC הבאים:

• הפרוטוקול External Processing או ext_proc.

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

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

• פרוטוקול ההרשאה החיצונית או ext_authz.

  הפרוטוקול הזה נתמך רק בתוספי הרשאה.

  פרוטוקול ext_authz מעביר החלטות הרשאה לבקשות נכנסות לשירות חיצוני ועצמאי. ה-API הזה מאפשר לשירות התוסף להגיב לאירועים במחזור החיים של בקשת HTTP, כדי לקבל החלטת הרשאה מורכבת על ידי בדיקת הכותרות או המטא-נתונים של הבקשה.

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

אפשר לפרוס את שירותי התוספים האלה במכונות וירטואליות (VM) או ב-GKE, ולהגדיר קבוצת מכונות או קבוצת נקודות קצה ברשת (NEG) שתייצג את נקודות הקצה של השירותים האלה.

תרחיש לדוגמה של פריסה

בתרשים הבא מוצג תרחיש פריסה לדוגמה. אפשר לפרוס את שירות ה-backend של ה-callout עם שרת gRPC במשאב מחשוב שמנוהל על ידי המשתמש – כמו מכונה וירטואלית או אשכול Google Kubernetes Engine ‏ (GKE) – ולהציג אותו למאזן העומסים כשירות לקצה העורפי רגיל.

איך פועלים נכסי היתרונות המרכזיים ב-ext_proc

זוהי גרסה מקוצרת של ext_proc gRPC API.

// The gRPC API to be implemented by the external processing server
service ExternalProcessor {
  rpc Process(stream ProcessingRequest) returns (stream ProcessingResponse) {
  }
}

// Envoy sets one of these fields depending on the processing stage.
message ProcessingRequest {
  oneof request {
    HttpHeaders request_headers = 2;
    HttpHeaders response_headers = 3;
    HttpBody request_body = 4;
    HttpBody response_body = 5;
  }
}

message ProcessingResponse {
  oneof response {
    HeadersResponse request_headers = 1;
    HeadersResponse response_headers = 2;
    BodyResponse request_body = 3;
    BodyResponse response_body = 4;

    ImmediateResponse immediate_response = 7;
  }
}

אחרי קבלת הכותרות של בקשת HTTP, שרתי proxy של מאזן עומסים של אפליקציות ושל Secure Web Proxy שולחים את ההודעה ProcessingRequest לשירות התוסף, כשהשדה request_headers מוגדר לכותרות ה-HTTP מהלקוח.

שירות התוסף חייב להגיב להודעה ProcessingRequest בהודעה ProcessingResponse תואמת שמכילה את כל השינויים שהוגדרו בכותרות או בגוף של ההודעה ProcessingRequest. לחלופין, השירות יכול להגדיר את השדה immediate_response כדי ששרת ה-proxy של הרשת יסיים את עיבוד הבקשה וישלח את התגובה שצוינה בחזרה ללקוח.

באירועים REQUEST_HEADER ו-RESPONSE_HEADER, שירות התוסף יכול לשנות את כותרות ה-HTTP בבקשה או בתגובה. השירות יכול להוסיף, לשנות או למחוק כותרות על ידי הגדרת השדה request_headers או response_headers בהודעה ProcessingResponse בצורה המתאימה. משתמשים בשדה raw_value לכותרות.

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

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

בתוספים של מסלולים ותנועה, אפשר להפעיל נכסי יתרונות מרכזיים באופן אסינכרוני כשערך המאפיין observabilityMode של התוסף מוגדר כ-true ומצב העיבוד של גוף הבקשה הוא STREAMED (ברירת מחדל). השיחות עם ה-backend של התוסף מתבצעות באופן אסינכרוני, בלי להשהות את העיבוד של הבקשה הנוכחית. המערכת מתעלמת מהתשובות, אם יש כאלה.

מאפייני גישה בהסברים

במקרה של תוספי יתרונות מרכזיים שמשתמשים בפרוטוקול ext_proc, המאפיינים שהוגדרו נשלחים בהודעה ProcessingRequest. המאפיינים מאוחסנים בשדה מיפוי, בדרך כלל תחת מפתח כמו envoy.filters.http.ext_proc.

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

בדוגמה הבאה אפשר לראות את המבנה של ProcessingRequest.attributes:

attributes {
  key: "envoy.filters.http.ext_proc"
  value {
    fields {
      key: "request.host"
      value { string_value: "example.com" }
    }
    fields {
      key: "source.client_region"
      value { string_value: "US" }
    }
    // ... other forwarded attributes
  }
}

ההטמעה של שירות gRPC יכולה לגשת לערכים האלה מהמיפוי בהודעות ProcessingRequest שקיבלתם.

איך פועלים נכסי היתרונות המרכזיים ב-ext_authz

‫ext_authz API תומך רק בתוספי יתרונות מרכזיים של הרשאות.

גרסה מקוצרת של ה-API מוצגת בהמשך.

// A generic interface for performing authorization checks on incoming
// requests to a networked service.
service Authorization {
  // Performs an authorization check based on the attributes associated with
  // the incoming request and return status.
  rpc Check(CheckRequest) returns (CheckResponse) {
  }
}

message CheckRequest {
  // The request attributes.
  AttributeContext attributes = 1;
}

message CheckResponse {
  google.rpc.Status status = 1;
  oneof http_response {
    DeniedHttpResponse denied_response = 2;
    OkHttpResponse ok_response = 3;
  }
  google.protobuf.Struct dynamic_metadata = 4;
}

אחרי קבלת הכותרות של בקשת HTTP, מאזן העומסים שולח את ההודעה CheckRequest לשירות התוסף.

שירות התוסף צריך להשיב להודעה CheckRequest בהודעה תואמת CheckResponse שמכילה את הפרטים הבאים:

• ‫status: מציין את הסטטוס. ‫OK מציין שהבקשה מותרת. כל סטטוס אחר מציין שהבקשה נדחתה.

• ‫denied_response או ok_response: מציין אם התשובה מותרת או נדחית. לשדה הזה מצורפים מאפייני תגובת ה-HTTP הרלוונטיים לבדיקת הרשאה.

  • השדה ok_response משמש כשהשירות לאימות הרשאות מאשר את הבקשה. השירות יכול לשנות, להוסיף או להסיר כותרות של בקשות מקוריות ולעדכן כותרות של תגובות HTTP שנשלחות ללקוח. משתמשים בשדה raw_value לכותרות.

  • השדה denied_response משמש כשהבקשה נדחית על ידי שירות ההרשאות. השירות יכול לעדכן כותרות תגובת HTTP שנשלחות ללקוח.

  אם שירות התוסף מחזיר שם או ערך של כותרת שלא מותרים דרך ההודעה CheckResponse, הבקשה נדחית עם קוד הסטטוס 500 Internal Error. מידע על כותרות שאסורות מופיע במאמר בנושא מגבלות על שינוי כותרות.

• ‫dynamic_metadata: כולל מטא-נתונים אופציונליים לשימוש של כל התוספים שמופעלים אחרי תוסף ההרשאה, כמו תוספי תנועה.

מצבי עיבוד של הגוף

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

מצב ברירת המחדל הוא STREAMED, והוא מומלץ לרוב תרחישי השימוש.