בדף הזה מוסבר איך משתמשים בגבולות גישה לפרטי כניסה כדי ליצור אסימון גישה מסוג OAuth 2.0 עם הרשאות מצומצמות ל-Cloud Storage.
תהליך היצירה של אסימון עם הרשאות מצומצמות כולל את השלבים הבאים:
- מעניקים את התפקידים המתאימים ב-IAM לחשבון משתמש או לחשבון שירות.
- מגדירים גבולות גישה לפרטי הכניסה שקובעים את הרף העליון של ההרשאות שיהיו לחשבון המשתמש או לחשבון השירות.
- יוצרים אסימון גישה מסוג OAuth 2.0 לחשבון המשתמש או לחשבון השירות.
- מחליפים את אסימון הגישה מסוג OAuth 2.0 באסימון חדש שעונה על גבולות הגישה.
לאחר מכן תוכלו להשתמש באסימון הגישה החדש והמצומצם מסוג OAuth 2.0 כדי לאמת בקשות ל-Cloud Storage.
לפני שמתחילים
לפני שאתם משתמשים בגבולות גישה לפרטי הכניסה, חשוב לוודא שהמקרה שלכם עונה על הקריטריונים הבאים:
אתם צריכים לצמצם את ההרשאות רק ל-Cloud Storage, ולא לשירותים אחרים שלGoogle Cloud .
אם צריך לצמצם את ההרשאות לשירותים נוספים של Google Cloud, אפשר ליצור מספר חשבונות שירות ולהקצות קבוצת תפקידים שונה לכל חשבון שירות.
אפשר להשתמש באסימוני גישה מסוג OAuth 2.0 לצורך אימות. אי אפשר להגדיר גבולות גישה לסוגים אחרים של פרטי כניסה עם תוקף קצר.
בנוסף, צריך להפעיל את ממשקי ה-API הנדרשים:
-
Enable the IAM and Security Token Service APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.
מתן תפקידים ב-IAM
גבולות הגישה לפרטי הכניסה מגדירים רף עליון להרשאות שיהיו למשאב. הם יכולים להוריד מחשבון המשתמש הרשאות קיימות, אבל לא להוסיף הרשאות שאין לו.
לכן, צריך לתת לחשבון המשתמש תפקידים עם ההרשאות הנדרשות בקטגוריה של Cloud Storage או במשאב ברמה גבוהה יותר, למשל הפרויקט.
לדוגמה, נניח שאתם צריכים ליצור פרטי כניסה עם תוקף קצר והרשאות מצומצמות, שמאפשרים לחשבון שירות ליצור אובייקטים בקטגוריה:
- לכל הפחות, אתם צריכים לתת לחשבון השירות תפקיד שכולל את ההרשאה
storage.objects.create, למשל Storage Object Creator (roles/storage.objectCreator). גבולות הגישה לפרטי הכניסה צריכים לכלול את ההרשאה הזו. - תוכלו לתת גם תפקיד שכולל הרשאות נוספות, כמו Storage Object Admin (
roles/storage.objectAdmin). חשבון השירות יוכל להשתמש רק בהרשאות שמופיעות גם בתפקיד שניתן לו וגם בגבולות הגישה.
למידע נוסף על תפקידים מוגדרים מראש ב-Cloud Storage
הגדרת גבולות הגישה לפרטי הכניסה
גבולות גישה לפרטי הכניסה הם אובייקט שמכיל רשימה של כללים להגבלת הגישה. הכללים מורכבים מפרמטרים שמציינים את הרף העליון של ההרשאות שיהיו לחשבון המשתמש או לחשבון השירות. כדי להגדיר גבולות גישה לפרטי הכניסה, יוצרים אובייקט JSON שמפרט את הכללים להגבלת הגישה ואת הפרמטרים שלהם.
זוהי דוגמה לגבול גישה לפרטי כניסה:
{
"accessBoundary": {
"accessBoundaryRules": [
{
"availablePermissions": [
"inRole:ROLE_ID"
],
"availableResource": "//storage.googleapis.com/projects/_/buckets/BUCKET_NAME"
"availabilityCondition": {
"expression" : "CONDITION"
}
]
}
}
מחליפים את מה שכתוב בשדות הבאים:
-
ROLE_ID: המזהה של תפקיד מוגדר מראש או תפקיד בהתאמה אישית שמגדיר את הרף העליון של ההרשאות שיהיו למשאב. לדוגמה,roles/storage.objectViewer. כדי לציין כמה תפקידים, מוסיפים שורה חדשה עם הקידומתinRole:ואחריה מזהה התפקיד. רק ההרשאות שכלולות בתפקידים שצוינו יינתנו. -
BUCKET_NAME: השם של קטגוריית Cloud Storage שעליה חל הכלל.
CONDITION: אופציונלי. ביטוי תנאי שמציין את האובייקטים של Cloud Storage שאליהם יינתנו ההרשאות. לדוגמה, התנאי הבא נותן הרשאות רק לאובייקטים שהשם שלהם מתחיל ב-customer-a:resource.name.startsWith('projects/_/buckets/example-bucket/objects/customer-a')
מידע נוסף על יצירה והתאמה אישית של גבולות גישה לפרטי כניסה זמין במאמר רכיבים של גבול גישה לפרטי כניסה.
במאמר דוגמאות לגבולות גישה לפרטי כניסה מופיעות דוגמאות לתרחישי שימוש אפשריים בגבולות גישה לפרטי כניסה.
יצירת אסימון גישה מסוג OAuth 2.0
לפני שיוצרים פרטי כניסה עם תוקף קצר והרשאות מצומצמות, צריך ליצור אסימון גישה רגיל מסוג OAuth 2.0. אחר כך אפשר להחליף את פרטי הכניסה הרגילים בפרטי הגישה המצומצמים. כשיוצרים את אסימון הגישה, צריך להשתמש ב-OAuth 2.0 בהיקף https://www.googleapis.com/auth/cloud-platform.
כדי ליצור אסימון גישה לחשבון שירות, אפשר להשתמש בהרשאה באמצעות OAuth 2.0 משרת-לשרת או ב-Service Account Credentials API כדי ליצור אסימון גישה מסוג OAuth 2.0.
איך יוצרים אסימוני גישה מסוג OAuth 2.0? תוכלו גם להשתמש ב-OAuth 2.0 Playground כדי ליצור אסימון גישה לחשבון Google שלכם.
החלפת אסימון הגישה מסוג OAuth 2.0
אחרי שיצרתם אסימון גישה מסוג OAuth 2.0, תוכלו להחליף אותו באסימון בהיקף שעומד בגבולות הגישה לפרטי הכניסה. בדרך כלל התהליך הזה כולל ברוקר וצרכן של האסימון:
ברוקר האסימון אחראי להגדיר את גבולות הגישה לפרטי הכניסה ולהחליף את אסימון הגישה באחד עם היקף מצומצם.
ברוקר האסימון יכול להשתמש בספריית אימות נתמכת כדי להחליף אסימוני גישה אוטומטית, או לקרוא לשירות Security Token כדי להחליף אסימונים ידנית.
צרכן האסימון מבקש מברוקר האסימון גישה עם היקף מצומצם ואז משתמש בו כדי לבצע פעולה נוספת.
צרכן האסימון יכול להשתמש בספריית אימות נתמכת כדי לרענן את אסימוני הגישה באופן אוטומטי לפני שהתוקף שלהם פג. לחלופין, הוא יכול לרענן ידנית את האסימונים, או לאפשר לתוקף של האסימונים לפוג בלי לרענן אותם.
יש שתי דרכים להחליף את אסימון הגישה באסימון עם היקף מצומצם:
החלפת אסימונים בצד הלקוח (מומלץ): לקוחות מקבלים חומרים קריפטוגרפיים משרת Security Token Service API. החומרים הקריפטוגרפיים מאפשרים ללקוחות ליצור אסימונים עם היקף מצומצם עם כללים שונים של גבולות הגישה לפרטי הכניסה באופן עצמאי בצד הלקוח למשך זמן מוגדר (לדוגמה, שעה אחת). הגישה הזו מפחיתה את זמן האחזור ומשפרת את היעילות, במיוחד עבור לקוחות שנדרשים לעדכן לעיתים קרובות את כללי הגבלת הגישה לפרטי הכניסה. השיטה הזו גם יעילה יותר לאפליקציות שצריכות ליצור הרבה אסימונים ייחודיים עם הרשאות מוגבלות. זהו הגישה המומלצת כי היא מספקת ביצועים טובים יותר, יכולת הרחבה ותאימות לתכונות עתידיות.
החלפת אסימונים בצד השרת: לקוחות מבקשים אסימון חדש בהיקף מצומצם משרת Security Token Service API בכל פעם שמשתנה כלל של Credential Access Boundary. הגישה הזו פשוטה, אבל היא מחייבת שליחה של בקשה לשרת של Security Token Service API וקבלת תשובה ממנו עבור כל בקשה ליצירת אסימון עם הרשאות מוגבלות. הגישה הזו מומלצת רק ללקוחות שנדרשת להם ספריית לקוח שלא תומכת בהחלפת אסימונים בצד הלקוח, בגלל הטיפול בבקשות לאסימונים עם היקף מצומצם באמצעות ה-API של Security Token Service.
החלפת טוקנים בצד הלקוח
אם אתם יוצרים את הברוקר ואת הצרכן של האסימון בשפה הבאה, תוכלו להשתמש בספריית האימות של Google כדי להחליף ולרענן אסימונים אוטומטית באמצעות הגישה בצד הלקוח.
Java
ב-Java, אפשר להחליף או לרענן אסימונים אוטומטית באמצעות ארטיפקט של com.google.auth:google-auth-library-cab-token-generator החל מגרסה 1.32.1.
כדי לבדוק את גרסת הארטיפקט, מריצים את פקודת Maven הבאה בספריית האפליקציות:
mvn dependency:list -DincludeArtifactIds=google-auth-library-cab-token-generator
כך הברוקר יכול ליצור אסימונים עם היקף מצומצם:
כך צרכן האסימון יכול להשתמש ב-handler של רענון כדי לקבל ולרענן אוטומטית אסימונים עם היקף מצומצם:
החלפת טוקנים בצד השרת
בקטע הזה מתוארות השיטות הבאות שבהן אפשר להשתמש כדי להחליף אסימונים באמצעות הגישה בצד השרת:
איך מחליפים ומרעננים אוטומטית את אסימון הגישה באמצעות גישה בצד השרת
אם אתם יוצרים את הברוקר ואת הצרכן של האסימון באחת מהשפות הבאות, תוכלו להשתמש בספריית האימות של Google כדי להחליף ולרענן אסימונים אוטומטית באמצעות הגישה של יצירת אסימונים בצד השרת:
Go
ב-Go, אפשר להחליף או לרענן אסימונים אוטומטית באמצעות חבילת golang.org/x/oauth2 החל מגרסה v0.0.0-20210819190943-2bc19b11175f.
כדי לבדוק את גרסת החבילה, מריצים את הפקודה הבאה בספריית האפליקציות:
go list -m golang.org/x/oauth2
כך הברוקר יכול ליצור אסימונים עם היקף מצומצם:
כך צרכן האסימון יכול להשתמש ב-handler של רענון כדי לקבל ולרענן אוטומטית אסימונים עם היקף מצומצם:
Java
ב-Java, אפשר להחליף או לרענן אסימונים אוטומטית באמצעות ארטיפקט של com.google.auth:google-auth-library-oauth2-http החל מגרסה 1.1.0.
כדי לבדוק את גרסת הארטיפקט, מריצים את פקודת Maven הבאה בספריית האפליקציות:
mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
כך הברוקר יכול ליצור אסימונים עם היקף מצומצם:
כך צרכן האסימון יכול להשתמש ב-handler של רענון כדי לקבל ולרענן אוטומטית אסימונים עם היקף מצומצם:
Node.js
ב-Node.js, אפשר להחליף או לרענן אסימונים אוטומטית באמצעות חבילת google-auth-library החל מגרסה 7.9.0.
כדי לבדוק את גרסת החבילה, מריצים את הפקודה הבאה בספריית האפליקציות:
npm list google-auth-library
כך הברוקר יכול ליצור אסימונים עם היקף מצומצם:
כך צרכן האסימון יכול לספק handler של רענון כדי לקבל ולרענן אוטומטית אסימונים עם היקף מצומצם:
Python
ב-Python, אפשר להחליף או לרענן אסימונים אוטומטית באמצעות חבילת google-auth החל מגרסה 2.0.0.
כדי לבדוק את גרסת החבילה, מריצים את הפקודה הבאה בסביבה שבה החבילה מותקנת:
pip show google-auth
כך הברוקר יכול ליצור אסימונים עם היקף מצומצם:
כך צרכן האסימון יכול לספק handler של רענון כדי לקבל ולרענן אוטומטית אסימונים עם היקף מצומצם:
איך מחליפים ומרעננים ידנית את אסימון הגישה
הברוקר של האסימון יכול להשתמש ב-API של Security Token Service כדי להחליף את אסימון הגישה באחד אחר עם היקף מצומצם ולתת את האסימון המצומצם לצרכן.
כדי להחליף את אסימון הגישה, משתמשים ב-method הבא ב-HTTP ובכתובת ה-URL:
POST https://sts.googleapis.com/v1/token
מגדירים את הכותרת Content-Type בבקשה ל-application/x-www-form-urlencoded. בגוף הבקשה, כוללים את השדות הבאים:
| שדות | |
|---|---|
grant_type |
משתמשים בערך |
options |
גבולות הגישה לפרטי הכניסה בפורמט JSON, עם קידוד באחוזים. |
requested_token_type |
משתמשים בערך |
subject_token |
אסימון הגישה מסוג OAuth 2.0 שאותו רוצים להחליף. |
subject_token_type |
משתמשים בערך |
התגובה היא אובייקט JSON שמכיל את השדות הבאים:
| שדות | |
|---|---|
access_token |
אסימון גישה מצומצם מסוג OAuth 2.0, שעומד בדרישות של גבולות הגישה לפרטי הכניסה. |
expires_in |
תוך כמה שניות יפוג התוקף של האסימון המצומצם. השדה הזה נכלל רק אם אסימון הגישה המקורי מייצג חשבון שירות. אם השדה הזה לא נכלל, לאסימון המצומצם יש את אותו זמן תפוגה כמו אסימון הגישה המקורי. |
issued_token_type |
הוא מכיל את הערך |
token_type |
הוא מכיל את הערך |
לדוגמה, אם גבולות הגישה בפורמט JSON שמורים בקובץ ./access-boundary.json, אפשר להשתמש בפקודה הבאה ב-curl כדי להחליף את אסימון הגישה. מחליפים את original-token באסימון הגישה המקורי:
curl -H "Content-Type:application/x-www-form-urlencoded" \ -X POST \ https://sts.googleapis.com/v1/token \ -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token_type=urn:ietf:params:oauth:token-type:access_token&requested_token_type=urn:ietf:params:oauth:token-type:access_token&subject_token=original-token" \ --data-urlencode "options=$(cat ./access-boundary.json)"
התגובה אמורה להיראות כך:
{
"access_token": "ya29.dr.AbCDeFg-123456...",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"token_type": "Bearer",
"expires_in": 3600
}
כשצרכן דורש אסימון עם היקף מצומצם, הברוקר מגיב גם עם האסימון המצומצם וגם עם מספר השניות עד לתפוגה שלו. אם פג התוקף של האסימון, השרת דוחה את הבקשה. כדי לרענן את האסימון המצומצם, הצרכן יכול לבקש אסימון חדש לפני שהתוקף יפוג.
המאמרים הבאים
- בקרת גישה ל-Cloud Storage
- איך יוצרים פרטי כניסה עם תוקף קצר לחשבון שירות
- יוצרים אסימון גישה מסוג OAuth 2.0 לחשבון שירות באחת מהשיטות הבאות:
- איך יוצרים אסימון גישה מסוג OAuth 2.0 למשתמשים?
- איך בודקים מה ההרשאות בכל אחד מהתפקידים המוגדרים מראש
- תפקידים בהתאמה אישית