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

אחסון אובייקטים במכשיר עם פער אוויר (air-gapped) של Google Distributed Cloud‏ (GDC) מסופק על ידי OTS‏ (ONTAP Select). ל-OTS יש מערכת משלה לניהול משתמשים באחסון אובייקטים. כל OTS פרטי כניסה של משתמש באחסון אובייקטים מאוחסנים כסוד באשכולות.

במאמר הזה מוסבר איך לבצע רוטציה של OTS פרטי הכניסה של משתמשים באחסון אובייקטים. מבצעים רוטציה של פרטי הכניסה של משתמשים באחסון אובייקטים במצבים הבאים:

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

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

כך עושים את זה:

  1. מוודאים שאתם עומדים בדרישות המוקדמות לשימוש במחשב נייד.
  2. מוודאים שאפשר להתחבר לאשכול OTS ולהריץ פקודות CLI של vserver object-store-server.
  3. מוודאים שאפשר להתחבר כאדמינים לאשכול התשתית ולאשכול הניהול באמצעות kubectl.

מזהה ייחודי (UID) של Translate

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

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

vserver object-store-server user show

הפלט הוא רשימה של מזהי UID, והוא אמור להיראות כך:

[
    "root",
    "k8ssa_gpc-system_inventory-export-images",
    "k8ssa_gpc-system_inventory-export-hardware",
    "k8su_test-user@example.com"
]

יש שלושה סוגי משתמשים:

משתמשים באחסון אובייקטים
UID סוג המשתמש שם הסוד מרחב שמות סודי
יחידה ארגונית שעברה תהליך רוט (root) אדמין objectstorage-tenant-bucket-controller-standard-system-s3-sa gpc-system
objectstorage-tenant-bucket-controller-standard-user-s3-sa
objectstorage-tenant-bucket-controller-nearline-user-s3-sa
k8ssa_&ltnamespace>_&ltsa> חשבון שירות Kubernetes object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> משתמש Kubernetes object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

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

מזהה המשתמש (UID), לא כולל המשתמש root, צריך להיות בפורמט k8ssa_<namespace>_<sa> או k8su_<username>. משיגים את <encoded-sa> או את <encoded-username>:

echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'

מחליפים את UID_SUFFIX ב-<sa> ב-UID, ומקבלים <encoded-sa>.

מחליפים את UID_SUFFIX ב-<username> ב-UID, ואז מקבלים <encoded-username>.

ביצוע רוטציה למפתח משתמש

  1. מתחברים לאשכול OTS.

  2. קבלת רשימה של מזהי משתמשים (UID) של אחסון אובייקטים.

    vserver object-store-server user show

    התוצאה היא רשימה של מזהי UID. דוגמאות אפשר למצוא במאמר תרגום UID. חוזרים על השלבים הבאים לכל UID ברשימה.

  3. מקבלים את מפתח הגישה הישן ואת המפתח הסודי של משתמש היעד.

    set -privilege advanced
vserver object-store-server user show -user UID

    מחליפים את UID במזהה המשתמש (UID) של משתמש היעד.

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

    vserver object-store-server user regenerate-keys -vserver root-admin -user UID

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

    kubectl --kubeconfig KUBECONFIG patch secret -n SECRET_NAMESPACE SECRET_NAME --type='json' -p='[{"op": "replace", "path": "/data/access-key-id", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}, {"op": "replace", "path": "/data/secret-access-key", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}]'

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

    • ‫KUBECONFIG: הנתיב לקובץ kubeconfig. שרת ה-API צריך להיות שרת ה-API של מישור הבקרה עבור המשתמש root. אם לא, הוא צריך להיות שרת ה-API לניהול.
    • ‫SECRET_NAME: שם הסוד של המשתמש, שאפשר להסיק אותו מהסעיף Translate UID. אם למשתמש יש כמה סודות של Kubernetes (כלומר, root user), replace with each secret name and run the command.
    • ‫SECRET_NAMESPACE: מרחב השמות הסודי של המשתמש, שאפשר לגזור אותו מהקטע Translate UID.
    • ‫ACCESS_KEY: מפתח הגישה החדש שנוצר בשלב הקודם.
    • ‫SECRET_KEY: המפתח הסודי החדש שנוצר בשלב הקודם.

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

    לדוגמה, כדי לשחזר את המשתמש root, צריך להפעיל מחדש את עומסי העבודה הבאים באשכול התשתית:

    kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system

אימות

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