הגדרת אימות ל-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 של Google Cloud באמצעות הפקודה הבאה:

   gcloud init

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

   הערה: אם התקנתם את ה-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 Reader לחשבון שירות שמוריד רק ארטיפקטים.
• אם קבוצות בארגון שלכם צריכות רמות גישה שונות למאגרי מידע ספציפיים, צריך להעניק גישה ברמת מאגר המידע ולא ברמת הפרויקט.
• חשוב לפעול לפי השיטות המומלצות לניהול פרטי כניסה.

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

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.

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

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