הגדרת מארחים וירטואליים בענן

אתם צופים במסמכי העזרה של Apigee Edge.
לעיון במאמרי העזרה של Apigee X. מידע

לקוחות Cloud עם חשבון בתשלום יכולים ליצור מארח וירטואלי בארגון.

מידע נוסף:

• מידע על מארחים וירטואליים
• הגדרת מארחים וירטואליים
• הגדרת TLS
• מאגרי מפתחות ומאגרי אמון

מי יכול ליצור ולשנות מארחים וירטואליים ב-Cloud

האפשרות ליצור ולשנות מארחים וירטואליים זמינה לחשבונות בתשלום רק ב-Edge Cloud. המשתמש שיוצר את המארח הווירטואלי צריך להיות בתפקיד אדמין ארגוני או בתפקיד מותאם אישית עם הרשאות לשינוי של מארח וירטואלי. למשתמשים בתפקידים אחרים אין הרשאה ליצור מארחים וירטואליים.

לדוגמה, לקוחות בתשלום יכולים:

• הפעלת TLS חד-כיווני ודו-כיווני
• מציינים את מאגר המפתחות/מאגר האמון שבו המארח הווירטואלי משתמש

אי אפשר ליצור או לשנות מארחים וירטואליים בחשבונות בחינם או בחשבונות לתקופת ניסיון, והם מוגבלים למארחים הווירטואליים שנוצרו עבורם בזמן הרישום ל-Edge. מידע נוסף על תוכניות התמחור של Edge זמין בכתובת https://apigee.com/api-management/#/pricing.

הדרישות להגדרת מארח וירטואלי ב-Cloud

בטבלה הבאה מפורטות הדרישות ליצירת מארח וירטואלי:

קטגוריה	דרישה	תיאור
סוג חשבון	בתשלום	בחשבונות בחינם ובחשבונות לניסיון לא ניתן ליצור או לשנות מארחים וירטואליים.
תפקיד משתמש	אדמין ארגוני	רק אדמין ארגוני או משתמש בתפקיד בהתאמה אישית שיש לו הרשאות לשינוי מארח וירטואלי יכולים ליצור מארח וירטואלי.
מספר המארחים הווירטואליים	20 לכל היותר	אתם יכולים ליצור עד 20 מארחים וירטואליים לכל ארגון או סביבה ב-Cloud. הערה: אין הגבלה על מספר המארחים הווירטואליים ב-Cloud הפרטי. רוב הארגונים/הסביבות משתמשים בשני מארחים וירטואליים: אחד ל-HTTP והשני לגישת HTTPS. יכול להיות שתצטרכו עוד מארחים וירטואליים אם בארגון או בסביבה שלכם מותר לגשת באמצעות שמות דומיינים שונים.
כתובת אתר הבסיס	כולל את הפרוטוקול	כשמגדירים את כתובת ה-URL הבסיסית למארח הווירטואלי, בממשק המשתמש או דרך ה-API, צריך לציין את הפרוטוקול (כלומר, http:// או https:// ) כחלק מכתובת ה-URL.
יציאה	443	אפשר ליצור מארח וירטואלי רק ביציאה 443. שימו לב שאפשר ליצור כמה מארחים וירטואליים ביציאה 443, כל עוד יש להם כתובות אימייל ייחודיות של מארחים והם כולם תומכים ב-TLS.
TLS	חובה	אפשר ליצור רק מארח וירטואלי שתומך ב-TLS ב-HTTPS. צריך כבר ליצור מאגר מפתחות, ואם רוצים גם מאגר אמון, שמכילים את האישור והמפתח של ה-TLS. צריך אישור חתום על ידי ישות מהימנה, כמו Symantec או VeriSign. לא ניתן להשתמש באישור עם חתימה עצמית. אם אתם זקוקים לגישה ל-HTTP, פנו אל התמיכה של Apigee Edge.
פרוטוקול TLS	TLS 1.2	ב-Edge in the Cloud יש תמיכה ב-TLS בגרסה 1.2 בלבד.
כינוי מארח	ייחודיים לארגון ולסביבה	כינוי המארח לא קיים בשילוב אחר של ארגון/סביבה.
שם דומיין	בבעלות הלקוח	עליך להיות הבעלים של שם הדומיין שצוין במארח הווירטואלי. ‏Edge בודק ששם הדומיין, כפי שמוגדר על ידי הכינוי של המארח, תואם למטא-נתונים באישור ה-TLS. באופן ספציפי, Edge בודק את הפרטים הבאים באישור: CN – שם נפוץ SAN – שם חלופי לנושא אפשר להשתמש בתווים כלליים לחיפוש ב-SAN או ב-CN, לדוגמה: *.myco.net. Edge גם מוודא שתוקף האישור לא פג.
תמיכה ב-SNI באפליקציות לקוח	כל אפליקציות הלקוח שמקבלות גישה למארח הווירטואלי חייבות לתמוך ב-SNI.	כל האפליקציות צריכות לתמוך ב-SNI.

יצירת מארח וירטואלי באמצעות דפדפן

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

כדי ליצור מארח וירטואלי באמצעות ממשק המשתמש של Edge:

1. נכנסים לכתובת apigee.com/edge.
2. בוחרים באפשרות ניהול > מארחים וירטואליים.
3. בוחרים את הסביבה, למשל prod או test.
4. בוחרים באפשרות + מארח וירטואלי כדי ליצור מארח וירטואלי, או בוחרים את השם של מארח וירטואלי קיים כדי לערוך אותו.
5. בטבלה שלמעלה מפורט מידע על האכלוס של שדות המארח הווירטואלי.

הגדרת מארח וירטואלי ל-TLS חד-כיווני

אובייקט XML שמגדיר את המארח הווירטואלי. לדוגמה, אובייקט ה-XML הבא מגדיר מארח וירטואלי ל-TLS חד-כיווני:

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>api.myCompany.com</HostAlias> 
    </HostAliases> 
    <Port>443</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>false</ClientAuthEnabled> 
        <KeyStore>ref://myTestKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
    </SSLInfo>
</VirtualHost>

בהגדרה הזו:

• מציינים את ה-name כ-myTLSVHost. משתמשים בשם כדי להפנות למארח הווירטואלי בשרת proxy של API או בקריאה ל-API.
• מציינים את כינוי המארח בתור api.myCompany.com. זהו הדומיין הגלוי לכולם שמשמש לגישה לממשקי ה-API, כפי שמוגדר על ידי הגדרת DNS ורשומת CNAME.
• מציינים את מספר היציאה בתור 443. אם לא מזינים את המזהה, היציאה מוגדרת ל-443 כברירת מחדל.
• מפעילים את TLS לפי הצורך.
  
  הרכיב <Enable> מוגדר כ-true כדי להפעיל TLS חד-כיווני, והרכיבים <KeyStore> ו-<KeyStore> מציינים את מאגר המפתחות ואת הכינוי של המפתח שנעשה בהם שימוש בחיבור ה-TLS.
  
  כדי להפעיל TLS דו-כיווני, מגדירים את <ClientAuthEnabled> כ-true ומציינים מאגר אישורים באמצעות האלמנט <TrustStore>. מאגר האמון מכיל את מנפיק האישור של הלקוח ואת שרשרת רשויות האישורים של האישור, שנדרשים.
  
  הערה: מאחר ש-Edge נתמך במקור ב-SSL, התג שבו משתמשים כדי להגדיר את TLS נקרא <SSLInfo>.

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

איך קובעים איך לציין את השם של מאגר המפתחות ומאגר האמון במארח הווירטואלי

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

    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>false</ClientAuthEnabled> 
        <KeyStore>ref://myTestKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
    </SSLInfo>

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

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

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

כשמשתמשים בהפניות למאגרי מפתחות ולמאגרי אמון, צריך להביא בחשבון את ההגבלה הבאה:

• אפשר להשתמש בהפניות של מאגר מפתחות ומאגרי אמון במארחים וירטואליים רק אם תומכים ב-SNI ומסיימים SSL בנתבי Apigee.
• אם יש לכם מאזן עומסים לפני נתבי Apigee ואתם מסיימים את TLS במאזן העומסים, לא תוכלו להשתמש בהפניות של מאגרי מפתחות ומאגרי אישורים באירוח וירטואלי.

הגדרת מארח וירטואלי עבור TLS דו-כיווני

כדי להפעיל TLS דו-כיווני, מגדירים את הרכיב <ClientAuthEnabled> כ-true ומציינים מאגר אמון באמצעות הפניה עם הרכיב <TrustStore>. מאגר האמון מכיל את מנפיק האישור של הלקוח ואת שרשרת רשויות האישורים של האישור, שנדרשים. בנוסף, צריך להגדיר את הלקוח בצורה נכונה ל-TLS דו-כיווני.

כדי ליצור מארח וירטואלי ל-TLS דו-כיווני, יוצרים אובייקט XML שמגדיר את המארח הווירטואלי:

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>api.myCompany.com</HostAlias> 
    </HostAliases> 
    <Port>443</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://myTestKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://myTestTruststoreRef</TrustStore> 
    </SSLInfo>
</VirtualHost>

בהגדרה הזו:

• כדי להפעיל TLS דו-כיווני, מגדירים את <ClientAuthEnabled> לערך true.
• מציינים את ההפניה למאגר האמון באמצעות הרכיב <TrustStore>. ה-Truststore מחזיקה את מנפיק האישור של הלקוח ואת שרשרת ה-CA של האישור, שנדרשת.

הגדרת מארח וירטואלי שמשתמש במפתח ובאישור של תקופת הניסיון בחינם ב-Apigee

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

אישור תקופת הניסיון בחינם ב-Apigee מוגדר לדומיין *.apigee.net. לכן, גם השדה <HostAlias> של המארח הווירטואלי צריך להיות בפורמט *.apigee.net.

אם מבצעים TLS דו-כיווני, עדיין צריך להגדיר את האלמנט <ClientAuthEnabled> לערך true, ולציין מאגר אישורים באמצעות הפניה עם האלמנט <TrustStore>, כפי שמתואר למעלה בקטע הגדרת מארח וירטואלי ל-TLS דו-כיווני.

אובייקט XML שמגדיר את המארח הווירטואלי באמצעות האישור והמפתח לניסיון החינמי של Apigee משמיט את הרכיבים <KeyStore> ו-<KeyAlias> ומחליף אותם ברכיב <UseBuiltInFreeTrialCert>, כפי שמוצג בהמשך:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

ערך ברירת המחדל של האלמנט <UseBuiltInFreeTrialCert> הוא false.

ל-TLS דו-כיווני, מגדירים את המארח הווירטואלי בתור:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <TrustStore>ref://myTestTruststoreRef</TrustStore>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

בממשק המשתמש של Edge, בוחרים באפשרות שימוש באישור מובנה לתקופת ניסיון בחינם כשיוצרים את המארח הווירטואלי שישתמש באישור ובמפתח של Apigee בחינם:

יצירת מארח וירטואלי

כדי ליצור את המארח הווירטואלי, פועלים לפי השלבים הבאים:

1. יוצרים רשומת DNS ורשומת CNAME לדומיין שגלוי לכולם, api.myCompany.com בדוגמה הזו, שמפנה אל [org]-[environment].apigee.net.
2. יוצרים ומגדירים מאגר מפתחות, שנקרא myTestKeystore בדוגמה הזו, באמצעות התהליך שמתואר כאן: יצירת מאגרי מפתחות ומאגרי אמון באמצעות ממשק המשתמש של Edge. בדוגמה הזו, צריך לוודא שמאגר המפתחות משתמש בשם החלופי myKeyAlias עבור האישור והמפתח הפרטי.
3. מעלים את האישור והמפתח למאגר המפתחות. מוודאים ששם הדומיין שצוין בתעודה תואם לכתובת החלופית של המארח שבה רוצים להשתמש למארח הווירטואלי.

4. יוצרים הפניה למאגר המפתחות באמצעות ממשק המשתמש או ה-API של Edge. ההפניה מציינת את שם מאגר המפתחות ואת סוג ההפניה כ-KeyStore. מידע נוסף על יצירה ושינוי של קובצי עזר זמין במאמר עבודה עם קובצי עזר.

5. יוצרים את המארח הווירטואלי באמצעות ה-API של Create a Virtual Host. חשוב לציין את ההפניה הנכונה למאגר המפתחות ואת הכינוי הנכון למפתח. כדי להשתמש ב-API, צריך להשתמש בקריאת ה-POST API הבאה כדי ליצור את מאגר המפתחות בשם myTLSVHost:

   curl -X POST -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts \
     -d '<VirtualHost name="myTLSVHost">
       <HostAliases>
         <HostAlias>api.myCompany.com</HostAlias>
       </HostAliases>
       <Port>443</Port>
       <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>false</ClientAuthEnabled>
         <KeyStore>ref://myTestKeystoreRef</KeyStore>
         <KeyAlias>myKeyAlias</KeyAlias>
       </SSLInfo>
     </VirtualHost>' \
     -u orgAdminEmail:password

   אם מבצעים TLS דו-כיווני עם הלקוח, צריך להגדיר את <ClientAuthEnabled> כ-true ולהציין את מאגר האישורים באמצעות האלמנט <TrustStore>. צריך להגדיר את הלקוח בצורה נכונה ל-TLS דו-כיווני, כלומר ל-Edge צריך להיות מאגר אמון שמכיל את המנפיק של אישור הלקוח ואת שרשרת האישורים. יוצרים את ה-Truststore באמצעות התהליך שמתואר כאן: יצירת מאגרי מפתחות ו-Truststore באמצעות ממשק המשתמש של Edge.

6. אם יש לכם שרתים proxy קיימים של API, צריך להוסיף את המארח הווירטואלי לרכיב <HTTPConnection> ב-ProxyEndpoint. המארח הווירטואלי מתווסף באופן אוטומטי לכל שרת ה-proxy החדש של ה-API. מידע נוסף מופיע בקטע הגדרת שרת proxy ל-API לשימוש במארח וירטואלי.

אחרי שמעדכנים את ה-Proxy ל-API לשימוש במארח הווירטואלי ויוצרים את רשומת ה-DNS ורשומת ה-CNAME בשביל הכינוי של המארח, אפשר לגשת לשרת ה-proxy ל-API כפי שמוצג בהמשך:

https://api.myCompany.com/v1/{project-base-path}/{resource-path}

לדוגמה:

https://api.myCompany.com/v1/weather/forecastrss?w=12797282

שינוי מארח וירטואלי

לקוחות Cloud בתשלום מבצעים שתי משימות עיקריות כדי לשנות מארח וירטואלי קיים:

1. שינוי הערך של הפניה למאגר מפתחות או למאגר אמון.
   
   הערה: אחרי שמגדירים ל-<KeyStore> או ל-<TrustStore> להשתמש בהפניה, אפשר לשנות את הערך של ההפניה בכל שלב. עם זאת, אם תרצו לשנות את <KeyStore> או את <TrustStore> כך שישתמשו במזהה אחר, או לשנות את <KeyAlias> כך שישתמש בכתובת אימייל חלופית, תצטרכו לפנות לתמיכה של Apigee Edge.
2. שינוי מאפייני ה-TLS של המארח הווירטואלי.

שינוי הערך של הפניה

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

לפני שמשתנים את הערך של ההפניה:

1. יוצרים מאגר מפתחות חדש ומעלים אישור ומפתח, כפי שמתואר במאמר יצירת מאגרי מפתחות ומאגרי אמון באמצעות ממשק המשתמש של Edge. במאגר המפתחות החדש, חשוב לוודא שאתם משתמשים באותו שם לכינוי המפתח שבו השתמשתם במאגר המפתחות הקיים.
2. אם צריך, יוצרים מאגר אמון חדש ומעלים אישור כפי שמתואר במאמר יצירת מאגרי מפתח ומאגרי אמון באמצעות ממשק המשתמש של Edge.
3. משנים את ההפניה כפי שמתואר בקטע עבודה עם הפניות.

שינוי מאפייני ה-TLS של המארח הווירטואלי

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

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

• הדומיין כפי שצוין בכינוי המארח לא נמצא בשימוש בארגון ובסביבה אחרים.
• שם הדומיין בבעלותכם. באופן ספציפי, Edge בודק שהפרטים הבאים בתעודה תואמים לכתובת החלופית של המארח:
  • CN – שם נפוץ
  • SAN – שם חלופי לנושא
  • Edge מאמת שלא פג התוקף של האישור.

כדי לשנות מארח וירטואלי באמצעות Edge API, מבצעים את הפעולות הבאות:

1. מעדכנים את המארח הווירטואלי באמצעות ה-API Update a Virtual Host. כשמשתמשים ב-API, צריך לציין את ההגדרה המלאה של המארח הווירטואלי בגוף הבקשה, ולא רק את הרכיבים שרוצים לשנות. בדוגמה הזו מגדירים את הערך של המאפיין proxy_read_timeout:

   curl -X PUT -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts/{vhost_name} \
     -d '<VirtualHost name="myTLSVHost">
       <HostAliases>
         <HostAlias>api.myCompany.com</HostAlias>
       </HostAliases>
       <Port>443</Port>
       <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>false</ClientAuthEnabled>
         <KeyStore>ref://myTestKeystoreRef</KeyStore>
         <KeyAlias>myKeyAlias</KeyAlias>
       </SSLInfo>
       <Properties>
          <Property name="proxy_read_timeout">50</Property>
            </Properties>
     </VirtualHost>' \
     -u orgAdminEmail:password

שינוי מארח וירטואלי כך שישתמש בהפניות למאגר המפתחות ולמאגר האמון

כל המארחים הווירטואליים החדשים של Edge בענן משתמשים בהפניה ל-keystore ול-truststore. באמצעות הפניות אפשר לשנות את מאגר המפתחות ואת מאגר האמון בלי לפנות לתמיכה של Apigee Edge.

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

עדכון מארח וירטואלי לשימוש בהפניה

כדי לעדכן את המארח הווירטואלי, פועלים לפי השלבים הבאים:

1. אם צריך, יוצרים מאגר מפתחות חדש ומעלים אישור כפי שמתואר במאמר יצירת מאגרי מפתחות ומאגרי אמון באמצעות ממשק המשתמש של Edge. אם כבר יש לכם מאגר מפתחות, תוכלו להגדיר הפניה שמפנה אליו.
2. יוצרים קובץ עזר חדש למאגר המפתחות.
3. אם צריך, יוצרים מאגר אמון חדש ומעלים אישור. אם כבר יש לכם מאגר אמון, תוכלו להגדיר הפניה שתוביל אליו.
4. יצירת קובץ עזר חדש ל-Truststore.
5. מעדכנים את המארח הווירטואלי כדי להגדיר את מאגר המפתחות, את הכינוי, את מאגר האמון ואת כל מאפייני ה-TLS האחרים. עומס העבודה של הקריאה הוא:

   curl -X PUT -H "Content-Type:application/xml" \
     https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/virtualhosts/{vhost_name} \
     -d '<VirtualHost  name="myTLSVHost">
           <HostAliases>
             <HostAlias>api.myCompany.com</HostAlias>
           </HostAliases>
           <Port>443</Port>
           <OCSPStapling>off</OCSPStapling>
           <SSLInfo>
             <Enabled>true</Enabled>
             <ClientAuthEnabled>true</ClientAuthEnabled>
             <KeyStore>ref://myKeyStore2Way</KeyStore>
             <KeyAlias>keyAlias</KeyAlias>
             <TrustStore>ref://myTrustStore2Way</TrustStore>
             <IgnoreValidationErrors>false</IgnoreValidationErrors>
           </SSLInfo>
         </VirtualHost>' \
       -u orgAdminEmail:pWord

6. כדי להשלים את התהליך, צריך לפנות לתמיכה של Apigee כדי להפעיל מחדש את נתב ה-Edge.