מעבר מ-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 APIs, אתם צריכים לפעול לפי הוראות ההעברה שמפורטות במסמך הזה, או שאתם יכולים להשתמש חלופות ל-OAuth Admin API.

מה משתנה

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

אי אפשר יותר ליצור או לנהל לקוחות 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

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

בדיקת השימוש ב-IAP OAuth Admin APIs

כדי לבדוק אם הפרויקט שלכם משתמש בממשקי IAP OAuth Admin API, צריך:

  1. במסוף Google Cloud , עוברים לדף IAP API Usage.

    מעבר אל IAP API Usage

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

  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, יוצא משימוש. מעכשיו, IAP משתמש בלקוח OAuth שמנוהל על ידי Google לגישה לדפדפן כברירת מחדל או כשלא מוגדר לקוח OAuth 2.0 באופן מפורש. לקוח OAuth 2.0 שמנוהל על ידי Google מגביל את הגישה לאפליקציות עם רכישות מתוך האפליקציה למשתמשים באותו ארגון, כשהם ניגשים לאפליקציות האלה דרך דפדפן.

בעקבות הוצאה משימוש של Identity-Aware Proxy (IAP) OAuth 2.0 Admin API, אי אפשר יותר להשתמש ב-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 מנוהלים על ידי Google לבין לקוחות OAuth בהתאמה אישית. אם האפליקציה שלכם דורשת Client ID מותאם אישית למיתוג או לגישה חיצונית, אתם יכולים להשתמש במסוף כדי ליצור את ה-Client ID. Google Cloud מידע נוסף על לקוחות OAuth בהתאמה אישית זמין במאמר התאמה אישית של הגדרת OAuth כדי להפעיל IAP.

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

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

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

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

    אם אתם משתמשים ב-Terraform או בכלים אחרים כדי להפוך את ההגדרה של 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 עם רכישות מתוך האפליקציה

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

gcloud

לפני שממשיכים לשלבים, צריך לוודא שיש לכם גרסה עדכנית של ה-CLI של 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. כדי להוסיף את CLIENT_ID שנשמר בעבר כלקוח פרוגרמטי, צריך לעדכן את הקובץ settings.json.

    {
    "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 מופיעות במאמר התקנת ה-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. כדי להעביר את האפליקציות, מריצים את הפקודה הבאה. כדי לנקות את מזהה הלקוח ב-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, ושהשירות לקצה העורפי משתמש בלקוח OAuth בניהול Google, מריצים את הפקודה gcloud compute backend-services describe. כדי לנקות את השדות האלה במהלך ההעברה, הפקודה gcloud compute backend-services update משתמשת ברווח בודד (" "), ש-Compute Engine API מפרש כהוראה להסיר את הערכים 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 שנשמר בעבר כלקוח פרוגרמטי, צריך לעדכן את הקובץ 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 הם אופציונליים, ואם אתם עובדים עם משאבים חדשים שמופעלת בהם רכישה מתוך האפליקציה, אתם יכולים להתעלם מהם.

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

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

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

gcloud

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

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

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

    היקף גלובלי

    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 שנשמר בעבר כלקוח פרוגרמטי, צריך לעדכן את הקובץ 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 הבא ל-BackendConfig Custom Resource Definition (CRD). ההגדרה הזו מאפשרת ל-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

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

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

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

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

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

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