שימוש ברשות אישורים (CA) בניהול הלקוח

‫MySQL   |  PostgreSQL   |  SQL Server

בדף הזה מוסבר איך להשתמש באפשרות של רשות אישורים (CA) בניהול הלקוח כמצב CA של השרת במופע Cloud SQL.

סקירה כללית

באפשרות של CA בניהול הלקוח, אתם מגדירים מאגר CA משלכם ו-CA ב-Certificate Authority Service (שירות CA). כשבוחרים באפשרות של רשות אישורים בניהול הלקוח, מגדירים את היררכיית רשות האישורים ומנהלים את הרוטציה של אישורי רשות האישורים עבור המופעים של Cloud SQL.

כדי להגדיר מכונת Cloud SQL לשימוש באפשרות CA בניהול הלקוח, צריך ליצור מאגר CA באותו אזור שבו נמצאת המכונה, ולפחות CA אחד במאגר הזה באמצעות שירות CA. רשות האישורים יכולה להיות רשות אישורים בסיסית או רשות אישורים משנית. יש גם אפשרות ליצור רשות אישורים משנית ב-CA Service ואז לשרשר את רשות האישורים המשנית לרשות אישורים חיצונית ברמה הבסיסית. כשמגדירים את המופע, מציינים את מאגר רשויות האישורים. הבקשה שלכם מועברת לחשבון שירות ספציפי לפרויקט, שיש לו הרשאה להשתמש במאגר רשויות האישורים. חשבון השירות מבקש רשות אישורים מהמאגר, ו-Cloud SQL משתמש ברשות האישורים הזו כדי לחתום על אישור השרת של המופע.

במצב CA של השרת במופע שלכם ב-Cloud SQL, אתם יכולים לבחור מבין שלוש האפשרויות הבאות:

• רשות אישורים פנימית לכל מופע
• רשות משותפת להנפקת אישורים (CA) בניהול Google
• רשות אישורים בניהול הלקוח

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

תהליך עבודה

כדי להשתמש באפשרות של CA בניהול הלקוח, תהליך העבודה הוא כזה:

1. יוצרים חשבון שירות לפרויקט Cloud SQL.
2. יוצרים מאגר CA בשירות CA.
3. יוצרים רשות אישורים בשירות CA.
4. מגדירים את המופע של Cloud SQL לשימוש ב-CA. כשמגדירים את המופע, מעניקים לחשבון השירות הרשאה לחתום על אישור השרת באמצעות מאגר רשויות האישורים שיצרתם.

לפני שמתחילים

לפני שמשתמשים באפשרות של רשות אישורים (CA) בניהול הלקוח, חשוב לוודא שאתם עומדים בדרישות הבאות.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירת חשבון שירות ספציפי ל-Cloud SQL, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד יצירת חשבונות שירות (roles/iam.serviceAccountCreator) בכל פרויקט בנפרד. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

כדי לקבל את ההרשאות שנדרשות ליצירת מאגר CA ו-CA, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד CA Service Operation Manager (מנהל תפעול של שירות CA) (roles/privateca.caManager) בשירות CA. להסבר על מתן תפקידים, קראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

יצירת חשבון שירות ספציפי לפרויקט

בפרויקט שבו אתם מתכננים ליצור את המכונות של Cloud SQL, יוצרים חשבון שירות ייעודי שיטפל בבקשה ליצור ולחתום על אישורי השרת עבור המכונות של Cloud SQL.

gcloud

מריצים את הפקודה הבאה כדי ליצור חשבון שירות לפרויקט Cloud SQL:

gcloud beta services identity create \
  --service=sqladmin.googleapis.com \
  --project=PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט שבו אתם מתכננים ליצור את מופעי Cloud SQL.

הפקודה יוצרת חשבון שירות בשם [e-mail] בפרויקט. רושמים את השם של חשבון השירות CA Service Certificate Requester.

יצירת מאגר רשויות אישורים

יוצרים מאגר CA בשירות CA.

אפשר ליצור מאגר CA באותו פרויקט שבו מתכננים ליצור את מכונות Cloud SQL, או ליצור את מאגר ה-CA בפרויקט אחר. עם זאת, אם תיצרו את מאגר רשויות האישורים בפרויקט אחר, יכול להיות ש-VPC Service Controls יחסום אתכם מלייצר מופעים של Cloud SQL, בהתאם למדיניות הארגון. כדי לפתור את הבעיה, צריך לוודא שהפרויקט שמארח את מאגר רשויות האישורים ואת רשות האישורים, והפרויקט שמארח את Cloud SQL, שייכים לאותו גבול גזרה לשירות. מידע נוסף זמין במאמרים בנושא גבולות גזרה לשירות וניהול גבולות גזרה לשירות.

כדי ליצור מאגר רשויות אישורים, פועלים לפי ההוראות במאמר בנושא יצירת מאגר רשויות אישורים. אפשר לאשר את ערכי ברירת המחדל של מאגר אישורי ה-CA, עם הגדרות החובה הבאות:

• יוצרים את מאגר רשויות האישורים באותו אזור שבו מתכננים ליצור את מכונת Cloud SQL. רשימת האזורים שנתמכים על ידי Cloud SQL מופיעה במאמר אזורים.
• מתן הרשאה לבקשות אישורים מבוססות-הגדרה.
• מתן הרשאה לשמות DNS בשמות חלופיים לנושא (SAN). כשמגדירים את מגבלות הזהות של מאגר רשויות האישורים, לא מגדירים הגבלות על הפורמט של שמות ה-DNS שעשויים להתנגש עם מה ש-Cloud SQL עשוי להוסיף ל-SAN.

מעניקים לחשבון השירות גישה למאגר רשויות האישורים

כדי לוודא שלחשבון השירות יש הרשאות לבקש ולחתום על אישורים עבור מופעי Cloud SQL, צריך להקצות לחשבון השירות את התפקיד הבא במאגר רשויות האישורים שיצרתם:

• roles/privateca.certificateRequester

gcloud

מריצים את הפקודה gcloud privateca pools כדי להעניק לחשבון השירות גישה למאגר תעודות ה-CA:

gcloud privateca pools add-iam-policy-binding CA_POOL_ID \
  --project=PROJECT_ID \
  --location=REGION \
  --member serviceAccount:SERVICE_ACCOUNT_NAME \
  --role=roles/privateca.certificateRequester

מחליפים את הפרטים הבאים:

• ‫CA_POOL_ID במזהה של מאגר הרשויות שמנפיקות את האישורים שיצרתם.
• ‫PROJECT_ID במזהה הפרויקט שבו אתם מתכננים ליצור את מופעי Cloud SQL.
• ‫REGION באזור שבו יצרתם את מאגר רשויות האישורים.
• SERVICE_ACCOUNT_NAME בשם של חשבון השירות CA Service Certificate Requester שיצרתם קודם לפרויקט.

יצירת רשות אישורים במאגר רשויות האישורים

יוצרים לפחות רשות אישורים אחת במאגר רשויות האישורים שיצרתם.

אפשר ליצור רשות אישורים (CA) בסיסית או רשות אישורים משנית.

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

כשמגדירים את הגודל והאלגוריתם של מפתח ה-CA, אפשר לבחור כל גודל ואלגוריתם של מפתח. ‫Cloud SQL מייצר אישורי שרת באמצעות מפתחות של עקומות אליפטיות מסוג EC P-384 (SHA-384), אבל מפתחות ההצפנה של CA לא חייבים להיות זהים.

אם יוצרים רשות אישורים משנית, צריך קודם ליצור ולהגדיר את רשות אישורי הבסיס.

• כדי ליצור רשות אישורים משנית ב-CA Service, פועלים לפי ההוראות שבמאמר יצירת רשות אישורים משנית.

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

הגדרת מכונה של Cloud SQL לשימוש ב-CA בניהול הלקוח

אתם יכולים להגדיר מופע של Cloud SQL לשימוש באפשרות של רשות אישורים בניהול הלקוח כשאתם יוצרים את המופע. אפשר גם לעדכן את מצב ה-CA של השרת במופע קיים משימוש ב-CA לכל מופע או באפשרות של CA משותף, לשימוש ב-CA בניהול הלקוח במקום זאת.

יצירת מופע

כדי ליצור מכונה של Cloud SQL שמשתמשת באפשרות של רשות אישורים (CA) בניהול הלקוח, מבצעים את הפעולות הבאות.

המסוף

אי אפשר להשתמש במסוף Google Cloud כדי ליצור מכונות שמשתמשות באפשרות CA בניהול הלקוח. אם יוצרים מופע באמצעותGoogle Cloud המסוף, ברירת המחדל היא מצב CA לכל מופע (GOOGLE_MANAGED_INTERNAL_CA).

כדי לבחור מצב CA בניהול הלקוח, צריך להשתמש בפקודה gcloud sql instances create.

gcloud

gcloud sql instances create "INSTANCE_NAME" \
  --database-version=DATABASE_VERSION \
  --project=PROJECT_ID \
  --region=REGION \
  --server-ca-mode=CUSTOMER_MANAGED_CAS_CA \
  --server-ca-pool=projects/PROJECT_ID_CAS/locations/REGION/caPools/CA_POOL_ID

מחליפים את הפרטים הבאים:

• ‫INSTANCE_NAME בשם המכונה של Cloud SQL שרוצים ליצור.
• ‫DATABASE_VERSION עם enum הגרסה של המכונה של Cloud SQL שרוצים ליצור. האפשרות של רשות אישורים בניהול הלקוח נתמכת רק ב-MySQL 8.0.30 ואילך.
• ‫PROJECT_ID במזהה הפרויקט שבו אתם מתכננים ליצור את מופעי Cloud SQL.
• ‫PROJECT_ID_CAS במזהה הפרויקט שבו יצרתם את CA_POOL_ID. יכול להיות שזה יהיה אותו פרויקט שבו רוצים ליצור את מכונת Cloud SQL, או פרויקט אחר.
• ‫REGION באזור שבו יצרתם את מאגר רשויות האישורים. צריך ליצור את המכונה הווירטואלית באותו אזור שבו נמצא מאגר רשויות האישורים.
• ‫CA_POOL_ID במזהה של מאגר הרשויות שמנפיקות את האישורים שיצרתם.

REST

כדי ליצור מכונת Cloud SQL שמשתמשת באפשרות של CA בניהול הלקוח, משתמשים בשיטה instances.insert ומציינים את המאפיינים הבאים:

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫PROJECT_ID מזהה הפרויקט שבו אתם מתכננים ליצור את מופעי Cloud SQL.
• ‫PROJECT_ID_CAS הוא מזהה הפרויקט שבו יצרתם את CA_POOL_ID. יכול להיות שזה יהיה אותו פרויקט שבו רוצים ליצור את מכונת Cloud SQL, או פרויקט אחר.
• ‫INSTANCE_ID השם של מופע Cloud SQL שרוצים ליצור.
• REGION האזור שבו יצרתם את מאגר הרשויות שמנפיקות אישורים. צריך ליצור את המכונה הווירטואלית באותו אזור שבו נמצא מאגר רשויות האישורים.
• ‫CA_POOL_ID במזהה של מאגר הרשויות שמנפיקות את האישורים שיצרתם.

ה-method של ה-HTTP וכתובת ה-URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

תוכן בקשת JSON:

{
  "name":"INSTANCE_ID",
  "region":"REGION",
  "databaseVersion": "DATABASE_VERSION",
  "settings":{
     "ipConfiguration":
      {
         "serverCaPool": "projects/PROJECT_ID_CAS/locations/REGION/caPools/CA_POOL_ID",
         "serverCaMode": "CUSTOMER_MANAGED_CAS_CA"
      }
   }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2025-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID_CSQL/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

עדכון מכונה לשימוש ב-CA בניהול הלקוח

לפני שמעדכנים מופע כדי להשתמש ב-CA בניהול הלקוח, צריך לבצע את הפעולות הבאות:

• מעיינים ברשימה של Google Cloud שירותים שלא תומכים בחיבורים למופעי Cloud SQL שמצורפים אליהם אישורים של רשות אישורים בניהול הלקוח. אם הפריסה שלכם מחייבת שימוש בשירות, יכול להיות שתצטרכו לדחות את העדכון.
• מוודאים שמשתמשים ב-MySQL 8.0.30 ואילך.
• אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או באחד מחיבורי השפה של Cloud SQL כדי להתחבר למכונה, ודאו שהם פועלים בגרסאות המינימליות הנדרשות. בשרת ה-proxy ל-Cloud SQL Auth, צריך לוודא שמשתמשים בגרסה 2.14.3 ואילך. במאמר דרישות של Cloud SQL Language Connectors מפורטות הגרסאות המינימליות הנדרשות של Cloud SQL Language Connectors.
• מוודאים שכבר יצרתם מאגר CA ונתתם לחשבון השירות גישה למאגר CA.
• מוודאים שיש לפחות רשות אישורים אחת במאגר רשויות האישורים.
• כדי למנוע שיבושים אחרי העדכון, צריך להוריד את האישורים מרשות האישורים שמנוהלת על ידי הלקוח ולהגדיר את לקוחות מסד הנתונים כך שיתנו אמון ברשות האישורים.

כדי לעדכן מופע של Cloud SQL כך שישתמש באפשרות של רשות אישורים (CA) בניהול הלקוח, צריך לבצע את השלבים הבאים.

הערה: אפשר להשתמש באותן פקודות גם בשלבים הבאים כדי לעדכן את מאגר רשויות האישורים עבור מופע Cloud SQL שכבר הוגדר לשימוש באפשרות של רשות אישורים בניהול הלקוח.

המסוף

אי אפשר להשתמש במסוף Google Cloud כדי לערוך את מצב ה-CA של השרת במכונה.

כדי לעדכן את מצב ה-CA של השרת של המכונה כך שישתמש ב-CA שמנוהל על ידי הלקוח, צריך להשתמש בפקודה gcloud sql instances patch במקום זאת. אחרי שתבצעו את השינוי, ההגדרה הזו תופיע במסוף Google Cloud כשצופים במופע.

gcloud

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

gcloud sql instances patch INSTANCE_NAME \
--server-ca-mode=CUSTOMER_MANAGED_CAS_CA \
--server-ca-pool=projects/PROJECT_ID_CAS/locations/REGION/caPools/CA_POOL_ID

בדגל --server-ca-mode, מוודאים שמציינים CUSTOMER_MANAGED_CAS_CA.

מחליפים את מה שכתוב בשדות הבאים:

• ‫INSTANCE_NAME: השם של מכונת Cloud SQL שרוצים להחיל עליה תיקון.
• ‫PROJECT_ID_CAS במזהה הפרויקט שבו נמצא CA_POOL_ID. יכול להיות שהפרויקט הזה זהה לפרויקט שבו נמצא מופע Cloud SQL, או שונה ממנו.
• ‫REGION באזור שבו יצרתם את מאגר רשויות האישורים. המכונה צריכה להיות באותו אזור כמו מאגר רשויות האישורים.
• ‫CA_POOL_ID: המזהה של מאגר רשויות האישורים שרוצים להקצות למכונה. אפשר להשתמש בפקודה הזו גם כדי לשנות את מאגר רשויות האישורים של מכונה שכבר הוגדרה לשימוש ב-CUSTOMER_MANAGED_CAS_CA

REST

כדי לעדכן מכונת Cloud SQL לשימוש באפשרות של CA בניהול הלקוח, משתמשים בשיטה instances.patch ומציינים את המאפיינים הבאים:

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫PROJECT_ID מזהה הפרויקט שבו נמצאת מכונת Cloud SQL.
• ‫INSTANCE_ID שם המופע של Cloud SQL שרוצים להחיל עליו תיקון.
• ‫PROJECT_ID_CAS הוא מזהה הפרויקט שבו יצרתם את CA_POOL_ID. יכול להיות שהפרויקט הזה יהיה זהה לפרויקט שבו נמצא מופע Cloud SQL או שונה ממנו.
• REGION האזור שבו יצרתם את מאגר הרשויות שמנפיקות אישורים. צריך ליצור את המכונה הווירטואלית באותו אזור שבו נמצא מאגר רשויות האישורים.
• ‫CA_POOL_ID המזהה של מאגר רשויות האישורים שרוצים להקצות למכונה. אפשר גם להשתמש בפקודה הזו כדי לשנות את מאגר רשויות האישורים של מכונה שכבר הוגדרה לשימוש ב-CUSTOMER_MANAGED_CAS_CA.

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

תוכן בקשת JSON:

{
  "settings":{
     "ipConfiguration":
      {
         "serverCaPool": "projects/PROJECT_ID_CAS/locations/REGION/caPools/CA_POOL_ID",
         "serverCaMode": "CUSTOMER_MANAGED_CAS_CA"
      }
   }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2025-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

החלפת מופע מ-CA בניהול הלקוח ל-CA משותף

אפשר לעדכן אינסטנס שמשתמש ברשות אישורים בניהול הלקוח כדי להשתמש ברשות אישורים משותפת (GOOGLE_MANAGED_CAS_CA). עם זאת, אי אפשר לעדכן אינסטנס שמוגדר להשתמש ברשות אישורים בניהול הלקוח כדי להשתמש ברשות אישורים לכל אינסטנס (GOOGLE_MANAGED_INTERNAL_CA).

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

כדי להעביר את המכונה למצב CA של השרת לשימוש ב-CA המשותף, צריך לבצע את הפעולות הבאות.

המסוף

אי אפשר להשתמש במסוף Google Cloud כדי לערוך את מצב ה-CA של השרת במכונה.

כדי לעדכן את מצב ה-CA של השרת במופע שלכם כך שישתמש ב-CA משותף במקום ב-CA בניהול הלקוח, צריך להשתמש בפקודה gcloud sql instances patch. אחרי שתבצעו את השינוי, ההגדרה הזו תופיע במסוף Google Cloud כשצופים במופע.

gcloud

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

gcloud sql instances patch INSTANCE_NAME \
--server-ca-mode=GOOGLE_MANAGED_CAS_CA \
--server-ca-pool=""

בפקודה, מבצעים את הפעולות הבאות:

• מחליפים את INSTANCE_NAME בשם של מופע Cloud SQL שרוצים להחיל עליו תיקון.
• מגדירים את הדגל --server-ca-mode לערך GOOGLE_MANAGED_CAS_CA.
• בדגל --server-ca-pool צריך לציין מחרוזת ריקה או "".

REST

כדי לעדכן מכונת Cloud SQL שמשתמשת ב-CA בניהול הלקוח כך שתשתמש באפשרות של CA משותף, משתמשים בשיטה instances.patch ומציינים את המאפיינים הבאים:

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫PROJECT_ID מזהה הפרויקט שבו נמצאת מכונת Cloud SQL.
• ‫INSTANCE_ID שם המופע של Cloud SQL שרוצים להחיל עליו תיקון.

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

תוכן בקשת JSON:

{
  "settings":{
     "ipConfiguration":
      {
         "serverCaPool": "",
         "serverCaMode": "GOOGLE_MANAGED_CAS_CA"
      }
   }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2025-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

פתרון בעיות

שגיאה	פתרון בעיות
מופיעה הודעת השגיאה הבאה: PERMISSION_DENIED: Permission privateca.certificates.create denied on CA_POOL_ID.	מוודאים שהענקתם את התפקיד roles/privateca.certificateRequester לחשבון השירות שיצרתם עבור פרויקט Cloud SQL. מידע נוסף מופיע במאמר מתן גישה לחשבון השירות למאגר רשויות האישורים.
מופיעה הודעת השגיאה הבאה: PERMISSION_DENIED: Request is prohibited by organization's policy vpcServiceControlsUniqueIdentifier VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER.	חשוב לוודא שהגדרתם את VPC Service Controls כך שהפרויקט שמארח את מאגר ה-CA ואת ה-CA של שירות CA והפרויקט שמארח את Cloud SQL שייכים לאותם גבולות גזרה לשירות. מידע נוסף זמין במאמרים בנושא גבולות גזרה לשירות וניהול גבולות גזרה לשירות.
מופיעה אחת מהודעות השגיאה הבאות: INVALID ARGUMENT Public key algorithm is not permitted by the CaPool's issuance policy. This CaPool's issuance policy does not permit passthrough subjects and/or subject alternative names, and thus can only be used with the REFLECTED_SPIFFE subject mode. Config issuance mode is not permitted by the CaPool's issuance policy.	בודקים את הגדרות התצורה של מאגר רשויות האישורים ושל רשות האישורים. חשוב לוודא שאתם עומדים בכל הדרישות שמפורטות במאמרים בנושא יצירת מאגר CA ויצירת CA במאגר CA.
מופיעה הודעת השגיאה הבאה: RESOURCE_EXHAUSTED	הערך הזה מייצג בעיות במכסה בשירות CA. מוודאים מה המכסה של CA Service בפרויקט. כדאי לבדוק אם אתם משתמשים בבקשות במאגר רשויות האישורים מחוץ ל-Cloud SQL. מידע נוסף זמין במאמר מכסות ומגבלות.
מופיעה הודעת השגיאה הבאה: NOT FOUND: parent resource CA_POOL_ID not found.	בודקים את מזהה הפרויקט, המיקום והשם של מאגר רשויות האישורים שציינתם כשיצרתם את מכונת Cloud SQL. חשוב לוודא שלא הקלדתם שגיאות.
מופיעה הודעת השגיאה הבאה: FAILED_PRECONDITION: There are no enabled CAs in the CaPool. Please ensure that there is at least one enabled Certificate Authority to issue a certificate.	צריך לוודא שיצרתם לפחות רשות אישורים אחת במאגר רשויות האישורים שציינתם כשנוצר מופע Cloud SQL, ושהרשות נמצאת במצב מופעל.
מופיעה הודעת השגיאה הבאה: FAILED_PRECONDITION: Per-Product Per-Project Service Account (P4 SA) SERVICE_ACCOUNT_NAME not found for project PROJECT_ID.	מוודאים שיצרתם את חשבון השירות לפרויקט Cloud SQL. מידע נוסף מופיע במאמר יצירת חשבון שירות ספציפי לפרויקט.
מופיעה הודעת השגיאה הבאה: INVALID ARGUMENT: Invalid format for server CA pool.	מוודאים שציינתם את מאגר אישורי ה-CA בפורמט הנכון: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL_ID
מופיעה הודעת השגיאה הבאה: INVALID ARGUMENT: The instance's server CA pool must be in the same region as the instance.	מוודאים שמאגר רשויות האישורים נמצא באותו אזור כמו מופע Cloud SQL שרוצים ליצור.

המאמרים הבאים

• מידע נוסף על היררכיות של רשויות אישורים ב-Cloud SQL
• הגדרת שם DNS מותאם אישית למכונה