מבוא
בדף הזה נסביר איך להשתמש ב-Service Control API v2 לבקרה על אישור בקשות של שירותים מנוהלים המשולבים עם Service Infrastructure. דף זה מיועד לבעלים של שירותים מנוהלים שרוצים לשלב בצורה עמוקה את השירותים שלהם ב-Google Cloud.
Service Infrastructure היא פלטפורמה בסיסית למפתחים ליצירה, לניהול, לאבטחה ולצריכה של ממשקי API ושירותים. נעשה בה שימוש במודל פשוט וגנרי של שימוש בשירות: הצרכן צורך שירות שמנוהל על ידי בעלים. המודל הזה משמש בכל Google APIs ו-Google Cloud APIs, מאחר שגם הם מבוססים על Service Infrastructure.
כשלקוח ניגש לשירות, כל הישויות המעורבות בגישה מחייבות בדרך כלל בדיקה של הסטטוס והמדיניות – כולל השירות לצרכן, הבעלים, המשתמש, האפליקציה, הרשת והמשאבים. התהליך הזה ב-Service Infrastructure נקרא 'בקרה על אישור בקשות', והוא כולל אימות, מתן הרשאות, ביקורת, הגבלת קצב של יצירת בקשות ועוד.
Service Control API v2
ב-Service Control API v2 מוצע method פשוט של services.check, שמספק בקרה על אישור בקשות לכל השירותים שמשולבים עם Service Infrastructure.
בעזרתו תוכלו לבצע את הפעולות הבאות בהפעלת method אחת:
- בדיקת סטטוס
- סטטוס התנהלות פוגעת
- סטטוס החיוב
- סטטוס הצרכן
- סטטוס השירות
- הפעלת שירותים
- אימות
- אסימון גישה מסוג Google OAuth
- JWT חתום בחשבון שירות ב-Google
- מתן הרשאות
- ביקורת
- יומני ביקורת של Cloud. יומן הביקורת משויך לשירות "externalaudit.googleapis.com".
כשמתבצעת קריאה משירות מסוים ל-Service Control API, הבעלים הוא גם הצרכן של ה-Service Control API. לכן, method services.check גם מבצע בקרה על אישור בקשות בקריאה ל-Service Control API.
כדי ששירות יבצע קריאה ל-Service Control API, עליכם להפעיל את Service Control API בפרויקט של הבעלים, וצריכות להיות לכם הרשאות מתאימות בשירות. מידע נוסף זמין במאמר תחילת השימוש ב-Cloud APIs ובמאמר בקרת גישה ל-Service Control API.
מאפייני הבקשות
כשלקוח ניגש לשירות, השירות צריך לתמצת את הגישה לבקשת API אחת או יותר – שניתנות לבדיקה באמצעות בקרה על אישור בקשות. ברוב המקרים, הגישות האלה הן בקשות API אמיתיות. בחלק מהמקרים, הגישה יכולה להיות משימות מורכבות של ייבוא נתונים או שאילתות SQL. במקרים כאלה, השירות צריך לתכנן את הגישה מבחינת קבוצה של בקשות API וירטואליות, ולבצע בקרה על אישור בקשות לגבי כל בקשה.
כדי לבצע בקרה על אישור בקשות באמצעות Service Control API, השירות צריך לבצע קריאה ל-method services.check עם מאפייני הבקשה הנדרשים. בטבלה הבאה מפורטים המאפיינים הנדרשים לבקרה על אישור בקשות.
למפרט המלא: AttributeContext
| מאפיין | תיאור | דוגמה |
|---|---|---|
origin.ip |
כתובת ה-IP של מבצע הקריאה. | "1.2.3.4" |
api.service |
שם השירות של ה-API. | "endpointsapis.appspot.com" |
api.operation |
שם ה-method של ה-API. | "google.example.hello.v1.HelloService.GetHello" |
api.version |
המחרוזת של גרסת ה-API. | "v1" |
api.protocol |
שם הפרוטוקול של ה-API. | "https" |
request.id |
מזהה בקשה ייחודי. | "123e4567-e89b-12d3-a456-426655440000" |
request.time |
מועד הבקשה | "2019-07-31T05:20:00Z" |
request.method |
שם ה-method של ה-HTTP. | "POST" |
request.scheme |
הסכימה של כתובת ה-URL. | "https" |
request.host |
הכותרת של מארח ה-HTTP. | "endpointsapis.appspot.com" |
request.path |
נתיב כתובת ה-URL. | "/v1/hello" |
request.headers |
הכותרות של בקשת HTTP. הכותרות הנדרשות הן: "authorization", "user-agent", "origin", "referer". | |
resource.name |
השם של משאב היעד | "projects/123/topics/news-feed" |
מאפייני המשאבים
כשלקוח ניגש לשירות, יכול להיות שהגישה תכלול לפחות משאב אחד בשירות – למשל קריאת אובייקט או יצירת מכונה וירטואלית. השירות יכול להשתמש בבקרה על אישור בקשות ב-Service Infrastructure כדי לבצע בקרת גישה על משאבים, שנתמכים על ידי IAM ויומני ביקורת של Cloud. אם לא נדרשת בקרת גישה בשירות שלכם, אפשר לדלג על הקטע הזה.
כדי לבצע בקרת גישה, השירות צריך להעביר מאפייני משאבים ל-method services.check, יחד עם מאפייני הבקשה.
בטבלה הבאה מפורטים מאפייני המשאבים הנדרשים לביצוע בקרת גישה:
| מאפיין | תיאור | דוגמה |
|---|---|---|
name |
שם המשאב | "projects/123/locations/global/instances/instance-1" |
type |
סוג המשאב. הפורמט הוא "{service}/{Kind}". | "endpointsapis.appspot.com/Instance" |
permission |
הרשאת המשאב. הפורמט הוא "{service}/{kinds}.{verb}". | "endpointsapis.appspot.com/instances.get" |
כדי לשפר את הביצועים והיעילות, בעזרת method services.check אפשר לבדוק הרשאות מרובות במשאב יחיד באמצעות קריאה אחת.
ביצוע בקרה על אישור בקשות
אחרי הפריסה של הגדרת השירות ל-Service Management API וכשהשירות מוכן למלא בקשות מלקוחות, אפשר להתחיל לבצע קריאות ל-services.check לשירות שנפרס. כדי לבצע בקרה על אישור בקשות בכל פעם שהשירות מקבל בקשה, צריך לבצע קריאה ל-services.check.
כדי להתנסות במהירות בבקרה על אישור בקשות, תוכלו להשתמש בפקודה gcurl כדי לקרוא ל-method services.check. מידע על שלבי ההגדרה הראשונית מופיע במאמר תחילת השימוש ב-Service Control API.
בדוגמה הבאה מוצגת המחשה לשימוש בפקודה gcurl כדי להפעיל את services.check על גבי HTTP:
gcurl -d '{
"service_config_id": "latest",
"attributes": {
"origin": {
"ip": "1.2.3.4"
},
"api": {
"service": "endpointsapis.appspot.com",
"operation": "google.example.hello.v1.HelloService.GetHello",
"version": "v1",
"protocol": "https"
}
},
"request": {
"id": "123e4567-e89b-12d3-a456-426655440000",
"time": "2019-07-31T05:20:00Z",
"scheme": "https",
"host": "endpointsapis.appspot.com"
"headers": {
"authorization": "Bearer xxx",
"user-agent": "curl/1.0"
}
},
"resources": [
]
}' https://servicecontrol.googleapis.com/v2/services/endpointsapis.appspot.com:check
{
}
התשובה מ-method services.check מציינת אם הבקרה על אישור הבקשות עברה. אם כן, התשובה צריכה להיות ריקה. אם לא, ב-status של התשובה יצוינו פרטי השגיאה שהשירות צריך להחזיר ללקוח. לעיתים קרובות השירות צריך לתרגם את פרטי השגיאות לפורמט משלו. השירות יכול גם להשתמש בפרטים האלה למטרות רישום ביומן ומעקב.
בשירותים בסביבת ייצור, צריך להשתמש באחת מספריות הלקוח ש-Google מספקת כדי לקרוא ל-Service Control API. הספריות האלה נוחות לשימוש ובעזרתן אפשר לטפל באופן אוטומטי בפעולות נפוצות כמו אימות. מידע נוסף זמין במאמר הסבר על ספריות לקוח.