מעבר מ-IAP OAuth Admin API

הפסקנו את התמיכה ב-Identity-Aware Proxy (IAP) OAuth Admin API. במדריך הזה מוסבר איך להעביר לקוחות OAuth קיימים ללקוחות OAuth בניהול Google. אם אתם לא משתמשים ב-IAP OAuth Admin API, השינוי הזה לא משפיע עליכם.

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

מה משתנה

אנחנו מוציאים משימוש את IAP OAuth Admin API, שכולל את ממשקי ה-API הבאים ואת קבוצות הפקודות של ה-CLI של gcloud לניהול ידני של לקוחות ומותגים ב-OAuth:

• ממשקי API של לקוח OAuth
• ממשקי API של מותגים
• ‫gcloud iap oauth-brands (create,‏ describe ו-list), כולל מסלולי ההפצה alpha ו-beta
• gcloud iap oauth-clients (create,‏ delete,‏ describe,‏ list ו-reset-secret), כולל מסלולי ההפצה alpha ו- beta

אי אפשר יותר ליצור או לנהל לקוחות OAuth בהתאמה אישית באמצעות IAP OAuth Admin API. במקום לנהל באופן ידני לקוחות OAuth 2.0, ב-IAP משתמשים בלקוח OAuth שמנוהל על ידי Google. כך קל יותר לנהל את לקוחות ה-OAuth, לצמצם שגיאות ידניות ולייעל את תהליכי הפריסה.

כדי להמשיך לספק מיתוג בהתאמה אישית, מומלץ להגדיר לקוחות OAuth בהתאמה אישית.

מה לא משתנה

אם אתם לא משתמשים ב-IAP OAuth Admin API, השינוי הזה לא משפיע עליכם.

ההוצאה משימוש לא משפיעה על לקוחות OAuth שאתם מגדירים ידנית באמצעות Compute Engine API,‏ App Engine API או מסוף Google Cloud . היא גם לא משפיעה על ממשקי API אחרים של IAP או על קבוצות פקודות של ה-CLI של gcloud (כולל מסלולי ההפצה alpha ו-beta שלהם) שמנהלים את מדיניות הגישה, ההגדרות או העברת ה-TCP של IAP – כמו gcloud iap web (לדוגמה, get-iam-policy ו-remove-iam-policy-binding), gcloud iap settings ו-gcloud iap tcp – כי הפקודות האלה משתמשות ב-API של IdentityAwareProxyAdminService ולא ב-API של IdentityAwareProxyOAuthService שהוצא משימוש.

אתם יכולים להמשיך ליצור הגדרות חדשות של מותגים ולקוחות ב-OAuth ולנהל אותן באמצעות מסוף Google Cloud . אתם לא צריכים להעביר את לקוחות ה-OAuth הקיימים. אתם יכולים להמשיך להשתמש בהם ולנהל אותם דרך מסוףGoogle Cloud במקום דרך IAP OAuth Admin API.

בדיקת השימוש בממשקי API של אדמין ב-IAP OAuth

כדי לבדוק אם בפרויקט שלכם נעשה שימוש בממשקי ה-API של IAP OAuth Admin:

1. נכנסים לדף IAP API Usage במסוף Google Cloud .

   כניסה לדף IAP API Usage

2. בוחרים את הפרויקט שבו רוצים לבדוק את השימוש ב-IAP OAuth Admin API.

3. ברשימה Select Graphs, בוחרים באפשרות Traffic by API method ולוחצים על OK.

4. בקטע Methods, מחפשים שיטות עם הקידומת google.cloud.iap.v1.IdentityAwareProxyOAuthService, שמציינת שהפרויקט משתמש ב-IAP OAuth Admin API.

תיאור מפורט

ב-22 בינואר 2025, הוצא משימוש ה-IAP OAuth 2.0 Admin API, שמשמש ליצירת לקוח IAP OAuth 2.0. כברירת מחדל, או כשלא מוגדר לקוח OAuth 2.0 באופן מפורש, IAP משתמש עכשיו בלקוח OAuth בניהול Google כדי לגשת לדפדפן. לקוח OAuth 2.0 שמנוהל על ידי Google מגביל את הגישה לאפליקציות שמופעל בהן IAP למשתמשים באותו ארגון, כשהם ניגשים לאפליקציות האלה דרך דפדפן.

הוצאנו משימוש את Identity-Aware Proxy (IAP) OAuth 2.0 Admin API, ולכן אי אפשר יותר להשתמש בו כדי ליצור או לנהל לקוחות OAuth. לקוחות OAuth שנוצרו לפני ההוצאה משימוש לא יבוטלו. אתם יכולים להמשיך להשתמש בלקוחות OAuth שיצרתם בעבר ולנהל אותם באמצעות מסוף Google Cloud .

אם יש לכם אפליקציות שמוגדרות עם לקוחות OAuth שנוצרו באמצעות IAP 2.0 Admin API או בדרך אחרת, האפליקציות האלה ימשיכו לפעול. לא צריך לבצע שינויים באפליקציות. עם זאת, אם הסקריפטים של האוטומציה או הכלים של Infrastructure as Code ‏ (IaC) משתמשים ב-IAP OAuth 2.0 Admin API כדי להגדיר לקוחות חדשים או לאחזר סודות לקוח של לקוחות קיימים, אתם צריכים לעדכן את הסקריפטים כך שהם לא ישתמשו ב-IAP OAuth 2.0 Admin API.

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

במאמר גישה פרוגרמטית מוסבר איך מגדירים לקוחות OAuth 2.0 שמנוהלים על ידי Google לאפליקציות שלכם.

אם יש לכם דרישה שלא נענית על ידי לקוח OAuth 2.0 בניהול Google, אתם יכולים לשתף לקוח OAuth אחד עם כמה אפליקציות IAP, וכך לא תצטרכו ליצור באופן ידני לקוח לכל אפליקציה חדשה.

הפעולות הנדרשות

• עדכון סקריפטים של אוטומציה

  אם אתם משתמשים ב-Terraform, ב-CLI של gcloud (gcloud iap oauth-brands או gcloud iap oauth-clients, כולל alpha ו-beta) או בכלים אחרים כדי להגדיר את IAP באופן אוטומטי, ואתם משתמשים ב-IAP OAuth 2.0 Admin API, אתם צריכים לעדכן את הסקריפטים של האוטומציה כך שישתמשו בלקוח שנוצר מראש או בלקוח OAuth בניהול Google עם IAP.

• הגדרת גישה פרוגרמטית לאפליקציות באמצעות לקוחות OAuth 2.0 בניהול Google

  אם כבר יש לכם אפליקציות שמוגנות באמצעות IAP ואתם מתכננים להעביר אותן באמצעות לקוח OAuth 2.0 בניהול Google, אתם יכולים להגדיר גישה פרוגרמטית לאפליקציות האלה על ידי הוספת לקוחות OAuth 2.0 לרשימת ההיתרים.

העברת משאבים שמופעל בהם IAP

כדי להעביר את המשאבים לשימוש בלקוח OAuth 2.0 בניהול Google, צריך לבצע את השלבים שמתאימים לסוג המשאב שרוצים להעביר, כמו משאב של Compute Engine.

העברת משאבים של App Engine עם IAP מופעל

כדי להעביר משאבים של App Engine שבהם מופעל IAP ומוגדר לקוח OAuth 2.0, צריך לבצע את השלבים שבקטע הזה.

gcloud

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

1. משתמשים ב-Google Cloud CLI כדי לבצע אימות.

   gcloud auth login
   

2. לוחצים על כתובת ה-URL שמופיעה ונכנסים לחשבון.

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

4. מריצים את הפקודה הבאה כדי לציין את הפרויקט שמכיל את האפליקציות שרוצים להמשיך להגן עליהן באמצעות IAP.

   gcloud config set project PROJECT_ID
   

5. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח שהוגדר ב-OAuth 2.0.

   gcloud app describe --format="value(iap.oauth2ClientId)"
   

   אם רוצים לאפשר גישה פרוגרמטית, שומרים את מזהה הלקוח מהפקודה הקודמת.

6. כדי להוסיף את לקוח OAuth 2.0 לרשימת ההיתרים לגישה פרוגרמטית, מבצעים פעולת קריאה-עדכון-כתיבה ב-API של הגדרות IAP.

   gcloud iap settings get --resource-type=app-engine --project=$PROJECT > settings.yaml
   

7. מעדכנים את הקובץ settings.yaml ומוסיפים את מזהה הלקוח ב-OAuth 2.0 שאוחזר קודם לכן בקטע programmaticClients, כמו בדוגמה הבאה.

   accessSettings:
     oauthSettings:
       programmaticClients:
       - CLIENT_ID
   

8. החלת ההגדרות החדשות על אפליקציית App Engine

   gcloud iap settings set settings.yaml --resource-type=app-engine --project=PROJECT_ID
   

9. כדי להעביר את האפליקציות, מריצים את הפקודה הבאה.

   gcloud iap web enable --resource-type=app-engine
   

API

1. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח ב-OAuth 2.0 שהוגדר.

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://appengine.googleapis.com/v1/apps/PROJECT_ID?fields=iap"
   

2. מריצים את הפקודה הבאה כדי לאחזר את הגדרות ה-IAP הקיימות לקובץ settings.json.

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/appengine-PROJECT_ID:iapSettings" > settings.json
   

3. צריך לעדכן את הקובץ settings.json כדי להוסיף את CLIENT_ID שנשמר בעבר כלקוח פרוגרמטי.

   {
       "accessSettings": {
         "oauthSettings": {
           "programmaticClients": [
             "CLIENT_ID"
           ]
         },
       },
   }
   

4. מריצים את הפקודה הבאה כדי לעדכן את הגדרות IAP.

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d "@settings.json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/appengine-PROJECT_ID:iapSettings"
   

5. מריצים את הפקודה הבאה כדי להכין קובץ settings.json.

     cat << EOF > settings.json
     {
     "iap":
         {
           "enabled":true
         }
     }
     EOF
   

6. מריצים את הפקודה הבאה כדי להעביר את האפליקציות.

     curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     -d @settings.json \
     "https://appengine.googleapis.com/v1/apps/PROJECT_ID?updateMask=iap"
   

העברת משאבים של Compute Engine עם IAP מופעל

כדי להעביר משאבים של Compute Engine שבהם מופעל IAP ומוגדר לקוח OAuth 2.0, צריך לבצע את השלבים שבקטע הזה.

gcloud

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

1. משתמשים ב-Google Cloud CLI כדי לבצע אימות.

   gcloud auth login
   

2. לוחצים על כתובת ה-URL שמופיעה ונכנסים לחשבון.

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

4. מריצים את הפקודה הבאה כדי לציין את הפרויקט שמכיל את האפליקציות שרוצים להמשיך להגן עליהן באמצעות IAP.

   gcloud config set project PROJECT_ID
   

5. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח שהוגדר ב-OAuth 2.0.

   היקף גלובלי

   
   gcloud compute backend-services describe BACKEND_SERVICE_NAME \
   --global \
   --format="value(iap.oauth2ClientId)"
   

   היקף אזורי

   
   gcloud compute backend-services describe BACKEND_SERVICE_NAME \
   --region REGION_NAME \
   --format="value(iap.oauth2ClientId)"
   

   אם רוצים לאפשר גישה פרוגרמטית, שומרים את מזהה הלקוח מהפקודה הקודמת.

6. כדי לתת ללקוח OAuth 2.0 גישה פרוגרמטית, מבצעים פעולת קריאה-עדכון-כתיבה ב-API של הגדרות IAP.

   היקף גלובלי

   gcloud iap settings get \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME > settings.yaml
   

   היקף אזורי

   gcloud iap settings get \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME \
       --region=REGION_NAME > settings.yaml
   

7. מעדכנים את הקובץ settings.yaml ומוסיפים את מזהה הלקוח ב-OAuth 2.0 שאוחזר קודם לכן בקטע programmaticClients, כמו בדוגמה הבאה:

   accessSettings:
     oauthSettings:
       programmaticClients:
       - CLIENT_ID
   

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

   היקף גלובלי

   gcloud iap settings set settings.yaml \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME

   היקף אזורי

   gcloud iap settings set settings.yaml \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME \
       --region=REGION_NAME

9. כדי להעביר את האפליקציות, מריצים את הפקודה הבאה. כדי למחוק את מזהה הלקוח ב-OAuth ואת הסוד ב-OAuth, צריך להעביר רווח בודד במירכאות (" ") בפקודה. השירות לקצה העורפי משתמש בלקוח OAuth שמנוהל על ידי Google.

   היקף גלובלי

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
       --global \
       --iap=enabled,oauth2-client-id=" ",oauth2-client-secret=" "
   

   היקף אזורי

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
       --region REGION_NAME \
       --iap=enabled,oauth2-client-id=" ",oauth2-client-secret=" "
   

10. כדי לוודא שהסרתם את מזהה הלקוח וסוד הלקוח של OAuth, ושהשירות לקצה העורפי משתמש בלקוח OAuth בניהול Google, מריצים את הפקודה gcloud compute backend-services describe. כדי לנקות את השדות האלה במהלך ההעברה, הפקודה gcloud compute backend-services update משתמשת ברווח בודד (" "), שממשק ה-API של Compute Engine מפרש כהוראה להסיר את הערכים oauth2ClientId ו-oauth2ClientSecret.

    היקף גלובלי

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
        --global
    

    היקף אזורי

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
        --region REGION_NAME
    

    אחרי שמריצים את הפקודה describe, בודקים את הקטע iap בפלט. ההעברה הצליחה אם השדה oauth2ClientId מכיל רווח בודד (' ') והשדה oauth2ClientSecret מכיל את גיבוב ה-SHA256‏ (36a9e7f1c95b82ffb99743e0c5c4ce95d83c9a430aac59f84ef3cbfab6145068) של רווח בודד.

API

1. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח ב-OAuth 2.0 שהוגדר.

   היקף גלובלי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME?fields=iap.oauth2ClientId"
   

   היקף אזורי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME?fields=iap.oauth2ClientId"
   

2. מריצים את הפקודה הבאה כדי לאחזר את הגדרות ה-IAP הקיימות לקובץ settings.json.

   היקף גלובלי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute/services/BACKEND_SERVICE_NAME:iapSettings" > settings.json
   

   היקף אזורי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute-REGION_NAME/services/BACKEND_SERVICE_NAME:iapSettings" > settings.json
   

3. מעדכנים את הקובץ settings.json כדי להוסיף את CLIENT_ID שנשמר קודם כלקוח פרוגרמטי.

   {
       "accessSettings": {
         "oauthSettings": {
           "programmaticClients": [
             "CLIENT_ID"
           ]
         },
       },
   }
   

4. מריצים את הפקודה הבאה כדי לעדכן את הגדרות IAP.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d "@settings.json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute/services/BACKEND_SERVICE_NAME:iapSettings"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d "@settings.json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute-REGION_NAME/services/BACKEND_SERVICE_NAME:iapSettings"
   

5. מריצים את הפקודה הבאה כדי להכין קובץ settings.json.

   cat << EOF > settings.json
   {
   "iap":
         {
           "enabled":true,
           "oauth2ClientId": " ",
           "oauth2ClientSecret": " "
         }
   }
   EOF
   

6. מריצים את הפקודה הבאה כדי להעביר את משאבי ה-IAP.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d @settings.json \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d @settings.json \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME"
   

7. כדי לוודא שמזהה הלקוח ב-OAuth לא מוגדר, מריצים את הפקודה הבאה ברמה הגלובלית או האזורית. אחרי שמריצים את הפקודה, בודקים את הפלט כדי לוודא שהשדה של מזהה הלקוח ב-OAuth ריק.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME"
   

Terraform

אם אתם מעבירים משאבים קיימים עם תמיכה ב-IAP לשימוש בלקוח OAuth בניהול Google, אתם צריכים לבטל באופן מפורש את ההגדרה של השדות oauth2_client_id ו-oauth2_client_secret. כדי לבטל את ההגדרה של השדות, מעדכנים את הערכים לתו רווח בודד, כמו בדוגמה הבאה:

resource "google_compute_backend_service" "default" {
  name                  = "tf-test-backend-service-external"
  protocol              = "HTTP"
  load_balancing_scheme = "EXTERNAL"
  iap {
    oauth2_client_id     = " "
    oauth2_client_secret = " "
  }
}

השדות oauth2_client_id ו-oauth2_client_secret הם אופציונליים, ואם אתם עובדים עם משאבים חדשים שמופעל בהם IAP, אתם יכולים להתעלם מהם.

מידע נוסף על השימוש ב-Terraform עם Google Cloudזמין במסמכי התיעוד של Terraform.

העברת משאבים של Cloud Run עם IAP מופעל

כדי להעביר משאבי Cloud Run שבהם מופעל IAP ומוגדר לקוח OAuth 2.0, צריך לבצע את השלבים שבקטע הזה.

gcloud

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

1. כדי לבצע אימות, משתמשים ב-Google Cloud CLI ומריצים את הפקודה הבאה.

   gcloud auth login
   

2. לוחצים על כתובת ה-URL שמופיעה ונכנסים לחשבון.

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

4. מריצים את הפקודה הבאה כדי לציין את הפרויקט שמכיל את האפליקציות שרוצים להמשיך להגן עליהן באמצעות IAP.

   gcloud config set project PROJECT_ID
   

5. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח שהוגדר ב-OAuth 2.0.

   היקף גלובלי

   
   gcloud compute backend-services describe BACKEND_SERVICE_NAME \
       --global \
       --format="value(iap.oauth2ClientId)"
   

   היקף אזורי

   
   gcloud compute backend-services describe BACKEND_SERVICE_NAME \
     --region REGION_NAME \
     --format="value(iap.oauth2ClientId)"
   

   אם רוצים לאפשר גישה פרוגרמטית, שומרים את מזהה הלקוח מהפקודה הקודמת.

6. כדי להוסיף לרשימת ההיתרים לקוח OAuth 2.0 לגישה פרוגרמטית, מבצעים פעולת קריאה-עדכון-כתיבה ב-IAP settings API.

   היקף גלובלי

   gcloud iap settings get \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME > settings.yaml
   

   היקף אזורי

   gcloud iap settings get \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME \
       --region=REGION_NAME > settings.yaml
   

7. מעדכנים את הקובץ settings.yaml ומוסיפים את מזהה הלקוח ב-OAuth 2.0 שאוחזר קודם לכן בקטע programmaticClients, כמו בדוגמה שמוצגת.

   accessSettings:
     oauthSettings:
       programmaticClients:
       - CLIENT_ID
   

8. מחילים את ההגדרות החדשות באפליקציית Compute Engine.

   היקף גלובלי

   gcloud iap settings set settings.yaml \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME
   

   היקף אזורי

   gcloud iap settings set settings.yaml \
       --resource-type=compute \
       --project=PROJECT_ID \
       --service=BACKEND_SERVICE_NAME \
       --region=REGION_NAME
   

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

   היקף גלובלי

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
       --global \
       --iap=enabled,oauth2-client-id=" ",oauth2-client-secret=" "
   

   היקף אזורי

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
       --region REGION_NAME \
       --iap=enabled,oauth2-client-id=" ",oauth2-client-secret=" "
   

10. כדי לוודא שמזהה הלקוח ב-OAuth לא מוגדר, מריצים את הפקודה הבאה ברמה הגלובלית או האזורית. אחרי שמריצים את הפקודה, בודקים את הפלט כדי לוודא שהשדה של מזהה הלקוח ב-OAuth ריק.

    היקף גלובלי

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
        --global
    

    היקף אזורי

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
        --region REGION_NAME
    

API

1. מריצים את הפקודה הבאה כדי לאחזר את מזהה הלקוח ב-OAuth 2.0 שהוגדר.

   היקף גלובלי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME?fields=iap.oauth2ClientId"
   

   היקף אזורי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME?fields=iap.oauth2ClientId"
   

2. מריצים את הפקודה הבאה כדי לאחזר את הגדרות ה-IAP הקיימות לקובץ settings.json.

   היקף גלובלי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute/services/BACKEND_SERVICE_NAME:iapSettings" > settings.json
   

   היקף אזורי

   curl -X GET \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute-REGION_NAME/services/BACKEND_SERVICE_NAME:iapSettings" > settings.json
   

3. מעדכנים את הקובץ settings.json כדי להוסיף את CLIENT_ID שנשמר קודם כלקוח פרוגרמטי.

   {
       "accessSettings": {
         "oauthSettings": {
           "programmaticClients": [
             "CLIENT_ID"
           ]
         },
       },
   }
   

4. מריצים את הפקודה הבאה כדי לעדכן את הגדרות IAP.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d "@settings.json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute/services/BACKEND_SERVICE_NAME:iapSettings"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d "@settings.json" \
   "https://iap.googleapis.com/v1/projects/PROJECT_ID/iap_web/compute-REGION_NAME/services/BACKEND_SERVICE_NAME:iapSettings"
   

5. מריצים את הפקודה הבאה כדי להכין קובץ settings.json.

   cat << EOF > settings.json
   {
   "iap":
         {
           "enabled":true,
           "oauth2ClientId": " ",
           "oauth2ClientSecret": " "
         }
   }
   EOF
   

6. מריצים את הפקודה הבאה כדי להעביר את המשאבים.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d @settings.json \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d @settings.json \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME"
   

7. כדי לוודא שמזהה הלקוח ב-OAuth לא מוגדר, מריצים את הפקודה הבאה ברמה הגלובלית או האזורית. אחרי שמריצים את הפקודה, בודקים את הפלט כדי לוודא שהשדה של מזהה הלקוח ב-OAuth ריק.

   היקף גלובלי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
   

   היקף אזורי

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/backendServices/BACKEND_SERVICE_NAME"
   

העברת משאבים של Google Kubernetes Engine עם IAP מופעל

מוסיפים את בלוק ה-IAP הבא להגדרת המשאב בהתאמה אישית (CRD) של BackendConfig. כך מפעילים את IAP עם לקוח OAuth 2.0 שמנוהל על ידי Google.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true

שימוש ב-JWT של חשבון שירות כדי לאמת את IAP

כדי לאמת את IAP בלי להשתמש ב-OAuth Admin API שהוצא משימוש, אתם יכולים להשתמש ב-JWT של חשבון שירות.

איך מקבלים סוד לקוח OAuth

כשיוצרים לקוח OAuth בהתאמה אישית במסוף Google Cloud , סוד הלקוח מוצג רק באותו זמן. אתם אחראים לאחסן את הסוד הזה בצורה מאובטחת. ‫Secret Manager הוא השירות המומלץ לאחסון מאובטח של סודות לקוח ב-OAuth.

אם אתם משתמשים ב-Secret Manager כדי לאחסן את סוד הלקוח ב-OAuth, עיינו במאמר גישה לגרסה של סוד כדי לקבל הוראות איך להשיג את סוד הלקוח.

איך בודקים אם משתמשים ב-IAP OAuth Admin API

כדי לבדוק אם בפרויקט שלכם נעשה שימוש בממשקי Admin API של OAuth של IAP, עיינו במאמר בדיקת השימוש בממשקי Admin API של OAuth.

חלופות לשימוש ב-OAuth Admin API

אם אתם צריכים לקבל פרטי כניסה של לקוח OAuth בלי להשתמש ב-OAuth API, אתם יכולים להשתמש בשיטות הבאות:

• מסוףGoogle Cloud : אפשר לקבל באופן ידני פרטי כניסה ל-OAuth דרך הדף Credentials.

• ‫Secret Manager: אתם יכולים לאחסן ולאחזר את הסוד באמצעות Secret Manager. במאמר google_secret_manager_secret מוסבר איך משתמשים ב-Secret Manager עם Terraform.

• אסימוני JWT של חשבון שירות: שימוש באסימוני JSON Web Tokens ‏ (JWT) של חשבון שירות לצורך אימות. כשמשתמשים ב-JWT של חשבון שירות, לא צריך להשתמש בלקוחות OAuth.