הגדרת אימות ל-Artifact Registry עבור npm

כשמשתמשים באפליקציית צד שלישי כדי להתחבר למאגר, צריך לבצע אימות ל-Artifact Registry.

לא צריך להגדיר אימות עבור Cloud Build או Google Cloudסביבות זמן ריצה כמו Google Kubernetes Engine ו-Cloud Run, אבל כדאי לוודא שההרשאות הנדרשות מוגדרות.

‫Node.js תומך בשתי שיטות לאימות בקשות למאגר שלכם ב-Artifact Registry:

• טוקני גישה: משתמשים בטוקני גישה כשהאימות באפליקציה מנוהל על ידי משתמש אנושי.
• אימות באמצעות סיסמה: משתמשים באפשרות הזו כשאפליקציה לא תומכת ב-Application Default Credentials, אבל כן תומכת באימות באמצעות שם משתמש וסיסמה.

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

1. התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

   gcloud init

   הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
2. (אופציונלי) הגדרת ברירות מחדל לפקודות של ה-CLI של gcloud.
3. אם אתם מתחברים למאגרי מידע מ-Windows, אתם צריכים להתקין את PowerShell.
4. יוצרים חשבון שירות שיפעל בשם האפליקציה.
5. אם אתם חדשים ב-npm, קראו את הסקירה הכללית כדי ללמוד על חבילות מוגדרות היקף ועל קובץ התצורה של הגדרות האימות.

יצירת טוקנים לאימות

כדי לאמת את החבילה ב-Artifact Registry, צריך קודם ליצור טוקן אימות. אחר כך תוכלו להשתמש באסימון הזה כשאתם שולחים בקשות מהחבילה שלכם אל Artifact Registry.

אפשר ליצור אסימון גישה של oauth2 באמצעות Google Cloud או אסימון oauth2l מחוץ ל- Google Cloud.

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

יצירת טוקן באמצעות gcloud

כדי ליצור אסימון גישה של oauth2 באמצעות Google Cloud, מריצים את הפקודה הבאה:

export ACCESS_TOKEN="oauth2accesstoken:$(gcloud auth print-access-token)"

עכשיו אפשר להפנות אל ACCESS_TOKEN כששולחים בקשות מחבילת Node.js ל-Artifact Registry.

יצירת טוקן בלי להשתמש ב-gcloud

כדי ליצור אסימון גישה באמצעות ה-CLI של oauth2l בלבד:

1. כדי להתקין את הגרסה העדכנית של oauth2l, מריצים את הפקודה הבאה:

   go install github.com/google/oauth2l@latest
   

2. מריצים את הפקודה הבאה:

   export ACCESS_TOKEN="oauth2l fetch --scope cloud-platform"
   

   ‫Google Cloud יוצר אסימון גיבוב SHA256 ומאחסן אותו במשתנה ACCESS_TOKEN. עכשיו אפשר להפנות אל ACCESS_TOKEN כששולחים בקשות מחבילת Node.js ל-Artifact Registry.

הגדרת אימות באמצעות סיסמה עם מפתחות של חשבון שירות

השתמשו בגישה הזו כשהאפליקציה שלכם ב-Node.js דורשת אימות באמצעות שם משתמש וסיסמה ספציפיים.

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

• מומלץ להשתמש בחשבון שירות ייעודי לאינטראקציה עם מאגרי מידע.
• מעניקים את התפקיד ב-Artifact Registry עם ההרשאות המינימליות שנדרשות לחשבון השירות. לדוגמה, הקצו את התפקיד "קריאה ב-Artifact Registry" לחשבון שירות שמוריד רק פריטי מידע שנוצרו בתהליך הפיתוח.
• אם קבוצות בארגון שלכם צריכות רמות גישה שונות למאגרי מידע ספציפיים, כדאי להעניק גישה ברמת מאגר המידע ולא ברמת הפרויקט.
• שיטות מומלצות לניהול פרטי כניסה

כדי ליצור חשבון שירות ולהגדיר אימות:

1. יוצרים חשבון שירות שיפעל בשם האפליקציה, או בוחרים חשבון שירות קיים שמשמש לאוטומציה.

   כדי להגדיר אימות באמצעות Artifact Registry, תצטרכו לדעת איפה נמצא קובץ המפתח של חשבון השירות. בחשבונות קיימים, אפשר לראות את המפתחות וליצור מפתחות חדשים בדף 'חשבונות שירות'.

   מעבר לדף 'חשבונות שירות'

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

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

2. מקצים לחשבון השירות את התפקיד הספציפי ב-Artifact Registry כדי לתת גישה למאגר.

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

   gcloud auth activate-service-account ACCOUNT --key-file=KEY-FILE
   

   כאשר:

   • ‫ACCOUNT הוא המשתמש או חשבון השירות.
   • ‫KEY-FILE הוא הנתיב לקובץ המפתח בפורמט JSON של חשבון השירות.

4. מריצים את הפקודה הבאה כדי להדפיס את תצורת המאגר:

   gcloud artifacts print-settings npm [--project=PROJECT] \
   [--repository=REPOSITORY] [--location=LOCATION] --scope=@SCOPE-NAME --json-key=KEY-FILE
   

   כאשר:

   • ‫PROJECT הוא מזהה הפרויקט. אם לא מציינים את הדגל הזה, המערכת משתמשת בפרויקט הנוכחי או בפרויקט ברירת המחדל.
   • ‫REPOSITORY הוא המזהה של המאגר. אם הגדרתם מאגר ברירת מחדל של Artifact Registry, המערכת תשתמש בו אם לא תציינו את הדגל הזה בפקודה.
   • ‫LOCATION הוא המיקום האזורי או המיקום במספר אזורים של המאגר.

   • ‫SCOPE-NAME הוא שם ההיקף של npm שאותו רוצים לשייך למאגר.

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

     חבילות ללא היקף משויכות למרשם ברירת המחדל של npm, בדרך כלל המרשם הציבורי של npm. אם לא תציינו היקף, ההגדרות שיוחזרו יגדירו את המאגר ב-Artifact Registry כמאגר ברירת המחדל. הבעיה הזו יכולה לגרום לבעיות אם בפרויקטים של Node.js צריך להתקין חבילות גם ממאגר npm ציבורי וגם ממאגר Artifact Registry.

   • ‫KEY-FILE הוא הנתיב לקובץ מפתח JSON של חשבון השירות.

   הערה: הגדרות התצורה שמוחזרות כוללות כתובת אימייל של placeholder. כדי לפרסם חבילות npm, צריך להזין כתובת אימייל בהגדרות של npm. כתובת האימייל של ה-placeholder לא משמשת את Artifact Registry לאימות.

5. מוסיפים את הגדרות התצורה שהוחזרו לקובץ התצורה .npmrc בפרויקטים של Node.js. הקובץ הזה נמצא בדרך כלל באותה תיקייה כמו package.json. חשוב לוודא שאתם כוללים את ההגדרות האלה בפרויקטים של Node.js לחבילות שאתם מפרסמים, וגם בפרויקטים שיתקינו תלות ממאגר npm.

6. אם יש לכם מאגרי Node.js אחרים שאתם רוצים להתחבר אליהם, חזרו על השלבים הקודמים כדי לקבל את ההגדרות ולהוסיף אותן לקובץ .npmrc.

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

• הגדרת גישה למאגרי מידע
• מידע נוסף על ניהול מאגרים
• מידע נוסף על ניהול חבילות