מידע על אישור CA בסיסי של Apigee ועל סבב האישורים

הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

מידע על אישור CA בסיס

לכל ארגון Apigee יש אישור CA בסיסי שמנוהל על ידי Google, שמנפיק את אישור השרת שמשמש את שער הכניסה של זמן הריצה של Apigee לסיום TLS. כשלקוח פותח חיבור HTTPS למופע של Apigee, השרת מציג אישור שמשורשר ל-CA הבסיסי הזה. לקוחות שמאמתים את אישור השרת צריכים לבטוח ב-CA הבסיסי, באופן מרומז (כשתעבורת הנתונים עוברת דרך מאזן עומסים בניהול הלקוח שמסיים את ה-TLS) או באופן מפורש (כשהלקוח מתחבר ישירות לזמן הריצה של Apigee).

אישור ה-CA הבסיסי נחשף בתגובת ה-API‏ organizations.get בשדה caCertificates[]. השדה הוא מערך כי במהלך רוטציה, גם אישורי ה-CA הבסיסיים הנוכחיים וגם אלה שעתידים להיכנס לתוקף מוחזרים בו-זמנית, כדי שהלקוחות יוכלו לבטוח בשניהם לפני המעבר.

למה מתבצעת רוטציה של אישור CA בסיסי

לאישור CA בסיסי של Apigee יש תקופת תוקף ארוכה אבל מוגבלת (בדרך כלל 10 שנים). הוא מוחלף לפני שתוקפו פג, כך ש:

  • התוקף של האישור שמאבטח את זמן הריצה של Apigee לא פג בזמן השימוש.
  • ערוצי התקשורת הפנימיים בין רכיבי Apigee ממשיכים לפעול ללא הפרעה.

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

שלבי הסבב וציר הזמן

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

שלב תזמון אופייני מה יש בcaCertificates[] מה קורה
1. פורסם אישור חדש כשנה לפני שתוקף האישור הנוכחי יפוג הנוכחי והחדש (שניהם) ‫Apigee יוצרת את אישור ה-CA הבסיסי החדש ומוסיפה אותו למאגר האישורים של כל רכיב בבעלות Apigee. האישור החדש מופיע גם בתשובה של organizations.get, כדי שתוכלו לאחזר אותו ולהכין אותו להפעלה. סביבת זמן הריצה של Apigee ממשיכה להציג אישור שרת שנחתם על ידי רשות האישורים הבסיסית הנוכחית, כך שעדיין אין השפעה על לקוחות קיימים. ‫Apigee שולחת ללקוח התראה כשהשלב הזה מתחיל.
2. מעבר לאישור קצה בערך 60 יום לפני שתוקף האישור הנוכחי יפוג הנוכחי והחדש (שניהם) סביבת זמן הריצה של Apigee מתחילה להציג אישור שרת (עלה) חדש שנחתם על ידי רשות האישורים החדשה של הבסיס. לקוחות שסומכים רק על רשות האישורים הנוכחית ברמה הבסיסית לא יעברו את אימות ה-TLS אחרי שהשלב הזה יסתיים באזור שלהם. לקוחות שסומכים על שני האישורים (או רק על האישור החדש) ימשיכו לפעול. ‫Apigee שולחת ללקוח הודעה כשהשלב הזה מתחיל.
3. האישור הישן בוטל בערך 30 יום לפני שתוקף האישור הנוכחי יפוג חדש בלבד ‫Apigee מסירה את רשות האישורים (CA) הישנה ברמה הבסיסית ממאגרי המידע הפנימיים של אישורים מהימנים, ומפסיקה להחזיר אותה מ-organizations.get. לקוחות שעדיין בוטחים רק ברשות האישורים (CA) הישנה ברמה הבסיסית לא יכולים להתחבר. ‫Apigee שולחת ללקוח התראה כשהשלב הזה מתחיל.
4. הסבב הושלם בתאריך התפוגה המקורי חדש בלבד ‫Apigee מוחק לצמיתות את ה-CA הישן של הבסיס, וההחלפה מסתיימת. ה-CA הבסיסי החדש הוא עכשיו ה-CA הבסיסי היחיד, ומתחיל מחזור חדש של כ-10 שנים. ‫Apigee שולחת ללקוח הודעה כשהשלב הזה מסתיים.

על מי משפיע שינוי של תפקיד

האם נדרשת פעולה מצדכם כדי לבצע רוטציה תלוי באופן שבו הלקוחות מגיעים לסביבת זמן הריצה של Apigee:

דפוס גישה נדרשת פעולה? למה לבחור ב-
ניתוב חיצוני (MIG) עם מאזן עומסים חיצוני של אפליקציות (ALB) ב-Google Cloud לא מאזן העומסים החיצוני מסיים את ה-TLS באמצעות אישור שאתם מנהלים. הלקוחות נותנים אמון באישור שלכם, ולא באישור הבסיס של רשות האישורים של Apigee. הרוטציה לא משפיעה על הלקוחות האלה.
ניתוב פנימי (VPC), אפשרות TLS 1 (מאזן עומסים פנימי של אפליקציות HTTPS) לא מאזן העומסים הפנימי מסיים את ה-TLS באמצעות אישור שאתם מנהלים. הלקוחות נותנים אמון באישור שלכם, ולא באישור הבסיס של רשות האישורים של Apigee. הרוטציה לא משפיעה על הלקוחות האלה.
ניתוב פנימי (VPC), אפשרות TLS 2 (שם דומיין מוגדר במלואו פנימי שמוגדר כברירת מחדל) כן הלקוחות מתחברים ישירות למאזן העומסים הפנימי שמנוהל על ידי Apigee ומאמתים את אישור השרת שהונפק על ידי Apigee. כל לקוח צריך לתת אמון ב-CA הבסיסי החדש לפני המעבר לרוטציה.
חיבור TCP ישיר לכתובת ה-IP של הכניסה למכונת זמן הריצה (לדוגמה, דרך מאזן עומסים פנימי מסוג TCP) כן הלקוחות מאמתים את אישור השרת שהונפק על ידי Apigee. כל לקוח צריך לתת אמון ב-CA הבסיסי החדש לפני המעבר.
אפשרות ללא TLS (הדגל curl -k או כל לקוח שמדלג על אימות האישור) לא הלקוח לא מאמת את אישור השרת, ולכן לרוטציה אין השפעה פונקציונלית. האפשרות הזו לא מומלצת לשימוש מחוץ לסביבות בדיקה.

איך מתכוננים לרוטציה

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

שלב 1: גילוי של מופעי זמן הריצה של Apigee

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

# Ensure $AUTH and $PROJECT_ID are set in your environment
curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances \
  | jq -r '.instances[] | "\(.name)\t\(.host)"'

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

שלב 2: אחזור של אישורי CA בסיסיים נוכחיים ועתידיים

קריאת השדה caCertificates[] מתוך organizations.get. במהלך רוטציה, המערך הזה מכיל את רשות האישורים הבסיסית הנוכחית ואת רשות האישורים הבסיסית החדשה, כל אחת בקידוד base64:

curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID \
  | jq -r '.caCertificates[]' \
  | awk '/-----BEGIN/{i++}{print > ("ca_" i ".b64")}'

מפענחים כל רשומה לפורמט PEM ובודקים את תקופת התוקף כדי לזהות את האישור החדש:

for f in ca_*.b64; do
  base64 -d "$f" > "${f%.b64}.crt"
  echo "==> ${f%.b64}.crt"
  openssl x509 -in "${f%.b64}.crt" -noout -subject -issuer -dates
done

האישור עם התאריך המאוחר יותר notAfter הוא אישור הבסיס החדש של ה-CA.

שלב 3: מוסיפים את רשות הבסיס החדשה לאחסוני האישורים

מוסיפים את אישור ה-CA החדש לכל מאגר אישורים מהימן של לקוח שכרגע מהימן על ידי אישור ה-CA של Apigee. משאירים את רשות האישורים (CA) הנוכחית של הבסיס במקומה עד להשלמת המעבר, כדי שהחיבורים ימשיכו לפעול במהלך חלון המעבר. אחרי המעבר החד למערכת אחרת (cutover), אפשר להסיר את רשות האישורים הבסיסית הישנה מ-truststores.

ההליך המדויק תלוי בלקוח. דוגמאות למקרים נפוצים:

  • הוספת האישור למאגר האישורים המהימנים ברמת מערכת ההפעלה (לדוגמה, /etc/ssl/certs/ במערכות מבוססות Debian ואחריו update-ca-certificates).
  • הוספת האישור למאגר אישורים אמינים שמנוהל על ידי אפליקציה (לדוגמה, מאגר מפתחות של Java cacerts, חבילה של Nginx ssl_trusted_certificate או חבילת אישורים אמינים של Envoy validation_context).
  • הוספת האישור ל-Kubernetes Secret או ל-ConfigMap שמוטמעים בקבוצות ה-Pod של עומס העבודה.

שלב 4: מוודאים שהחיבור פועל עם רשות האישורים החדשה של הבסיס

אחרי שמכינים את רשות האישורים החדשה, צריך לוודא שבקשת HTTPS לזמן הריצה של Apigee מצליחה כשסומכים רק על האישור החדש:

# Ensure $ENV_GROUP_HOSTNAME and $INTERNAL_LOAD_BALANCER_IP are set
curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert NEW_CA_FILE \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

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

דוגמה: ניתוב פנימי (VPC), אפשרות TLS 2

בדוגמה הזו מוצגים שלבי הרוטציה של תבנית הגישה שמתועדת במאמר ניתוב פנימי (VPC), אפשרות TLS 2, שבה הלקוח מתחבר ישירות למאזן העומסים הפנימי של Apigee ומאמת את האישור בחתימה עצמית של Apigee. זהו דפוס הגישה שמושפע הכי הרבה מהחלפה.

לפני המעבר:

  1. מקבלים את כתובת ה-IP של מאזן העומסים הפנימי של Apigee: 
    export INTERNAL_LOAD_BALANCER_IP=$(curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances -s \
  | jq -r '.instances[0].host')
  2. מאחזרים את האישורים הבסיסיים הנוכחיים והחדשים לקבצים נפרדים ומזהים את האישור החדש: 
    curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID \
  | jq -r '.caCertificates[]' \
  | awk '/-----BEGIN/{i++}{print > ("ca_" i ".b64")}'

for f in ca_*.b64; do
  base64 -d "$f" > "${f%.b64}.crt"
done

# Identify the new root CA (latest notAfter):
openssl x509 -in ca_1.crt -noout -dates
openssl x509 -in ca_2.crt -noout -dates
  3. יוצרים מאגר אישורים משולב שמכיל גם את ה-CA הבסיסי הנוכחי וגם את ה-CA הבסיסי החדש, ומשתמשים בו לבקשת הבדיקה: 
    cat ca_1.crt ca_2.crt > cacert-combined.crt

curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert cacert-combined.crt \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

    אם הבקשה מצליחה, פורסים את cacert-combined.crt כמאגר האישורים המהימן של הלקוח. מאגר האישורים המשולב ימשיך לאמת את האישור הנוכחי היום, ויאמת את האישור החדש אחרי המעבר.

אחרי המעבר (בדרך כלל תוך כמה ימים מתאריך המעבר), מאמתים את הרוטציה על ידי בדיקה שהחיבור עדיין מצליח כשנותנים אמון רק באישור החדש:

curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert NEW_CA_FILE \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

אם הבקשה תאושר, תוכלו להסיר בבטחה את רשות האישורים הישנה מהמאגר שלכם.

התראות

‫Apigee שולח התראה לבעלי הפרויקט ולבעלי הארגון של הפרויקט שלכם Google Cloud בתחילת כל שלב של רוטציה. כל הודעה כוללת את שם השלב, את התאריך שבו השלב יחול על הארגון שלכם וקישור לדף הזה.

התראה פעולה מומלצת ללקוח
1. פורסם אישור חדש
(כשנה לפני התפוגה)		 מאחזרים את רשות האישורים הבסיסית החדשה מכתובת caCertificates[] ומוסיפים אותה לכל מאגר אישורים של לקוח שכרגע נותן אמון ברשות האישורים הבסיסית של Apigee. איך מתכוננים לרוטציה
2. החלפת אישור קצה
(~60 ימים לפני התפוגה)		 לפני שהשלב הזה יחול על האזור שלכם, צריך לוודא שכל הלקוחות שלכם נותנים אמון ב-CA הבסיסי החדש. אחרי השלב הזה, לקוחות שסומכים רק על רשות האישורים (CA) הישנה ברמה הבסיסית לא יכולים להתחבר.
3. האישור הישן בוטל
(כ-30 ימים לפני התפוגה)		 אחרי שהשלב הזה יחול על כל האזורים, תוכלו להסיר בבטחה את רשות האישורים הישנה מהמאגרים של הלקוחות.
4. הסבב הושלם
(בתאריך התפוגה המקורי)		 לא נדרשת כל פעולה. ה-CA הבסיסי הישן נמחק סופית וה-CA הבסיסי החדש הוא ה-CA הבסיסי היחיד בארגון.

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

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