ה-ABC של אבטחה ב-Kubernetes: אימות, הרשאה, ביקורת

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

אימות

ישנם שני סוגי משתמשים ב-Kubernetes:

• חשבונות שירות - חשבונות המנוהלים על ידי Kubernetes API;
• משתמש - משתמשים "רגילים" המנוהלים על ידי שירותים חיצוניים ובלתי תלויים.

ההבדל העיקרי בין הסוגים הללו הוא שעבור חשבונות שירות ישנם אובייקטים מיוחדים ב-Kubernetes API (הם נקראים כך - ServiceAccounts), שקשורים למרחב שמות ולסט של נתוני הרשאה המאוחסנים באשכול באובייקטים מסוג Secrets. משתמשים כאלה (חשבונות שירות) מיועדים בעיקר לנהל זכויות גישה ל-Kubernetes API של תהליכים הפועלים באשכול Kubernetes.

למשתמשים רגילים אין ערכים בממשק ה-API של Kubernetes: הם חייבים להיות מנוהלים על ידי מנגנונים חיצוניים. הם מיועדים לאנשים או לתהליכים החיים מחוץ לאשכול.

כל בקשת API משויכת לחשבון שירות, למשתמש או נחשבת לאנונימית.

נתוני אימות המשתמש כוללים:

• שם משתמש - שם משתמש (תלוי רישיות!);
• UID - מחרוזת זיהוי משתמש הניתנת לקריאה במכונה שהיא "עקבית וייחודית יותר משם המשתמש";
• קבוצות - רשימת הקבוצות אליהן משתייך המשתמש;
• נוסף - שדות נוספים שניתן להשתמש בהם על ידי מנגנון ההרשאה.

Kubernetes יכול להשתמש במספר רב של מנגנוני אימות: אישורי X509, Tokens Bearer, Proxy אימות, HTTP Basic Auth. באמצעות מנגנונים אלה, אתה יכול ליישם מספר רב של סכימות הרשאה: מקובץ סטטי עם סיסמאות ועד OpenID OAuth2.

יתרה מכך, ניתן להשתמש בכמה סכימות הרשאות בו-זמנית. כברירת מחדל, האשכול משתמש ב:

• אסימוני חשבון שירות - עבור חשבונות שירות;
• X509 - למשתמשים.

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

אישורים למשתמשים (X.509)

הדרך הקלאסית לעבוד עם תעודות כוללת:

• יצירת מפתח:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• הפקת בקשת אישור:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• עיבוד בקשת אישור באמצעות מפתחות ה-CA של אשכול Kubernetes, השגת אישור משתמש (כדי לקבל אישור, עליך להשתמש בחשבון שיש לו גישה למפתח ה-CA של אשכול Kubernetes, אשר כברירת מחדל נמצא ב /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• יצירת קובץ תצורה:
  • תיאור אשכול (ציין את הכתובת והמיקום של קובץ אישור ה-CA עבור התקנת אשכול ספציפית):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • או איך לאאפשרות מומלצת - אינך צריך לציין את אישור השורש (ואז kubectl לא יבדוק את נכונות שרת ה-API של האשכול):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • הוספת משתמש לקובץ התצורה:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • הוספת הקשר:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

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

    kubectl config use-context mynewuser-context

לאחר המניפולציות לעיל, בקובץ .kube/config תיווצר תצורה כזו:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

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

• certificate-authority
• client-certificate
• client-key

לשם כך, ניתן לקודד את הקבצים שצוינו בהם באמצעות base64 ולרשום אותם ב-config, תוך הוספת הסיומת לשם המפתחות -data, כלומר לאחר שקיבל certificate-authority-data וכו '

תעודות עם kubeadm

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

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: נדרש כתובת לפרסם ניתן למצוא בתצורת ה-API-server, אשר כברירת מחדל נמצאת ב /etc/kubernetes/manifests/kube-apiserver.yaml.

התצורה שתתקבל תוצא ל-stdout. צריך לשמור את זה ~/.kube/config חשבון משתמש או לקובץ שצוין במשתנה סביבה KUBECONFIG.

לחפור עמוק יותר

למי שרוצה להבין את הנושאים המתוארים בצורה יסודית יותר:

• מאמר נפרד על עבודה עם תעודות בתיעוד הרשמי של Kubernetes;
• מאמר טוב מביטנאמי, שבה נוגעים בנושא התעודות מנקודת מבט מעשית.
• תיעוד כללי על אימות ב-Kubernetes.

הרשאה

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

לפני גרסה 1.6, Kubernetes השתמשה בסוג הרשאה בשם ABAC (בקרת גישה מבוססת תכונות). פרטים על זה ניתן למצוא ב תיעוד רשמי. גישה זו נחשבת כיום למורשת, אך אתה עדיין יכול להשתמש בה לצד סוגי אימות אחרים.

הדרך הנוכחית (וגמישה יותר) לחלוקת זכויות גישה לאשכול נקראת RBAC (בקרת גישה מבוססת תפקיד). הוא הוכרז יציב מאז הגרסה קוברנטס 1.8. RBAC מיישמת מודל זכויות שבו כל מה שלא מותר במפורש אסור.
כדי להפעיל את RBAC, עליך להפעיל את Kubernetes api-server עם הפרמטר --authorization-mode=RBAC. הפרמטרים נקבעים במניפסט עם תצורת שרת ה-API, אשר כברירת מחדל ממוקמת לאורך הנתיב /etc/kubernetes/manifests/kube-apiserver.yaml, בסעיף command. עם זאת, RBAC כבר מופעל כברירת מחדל, כך שככל הנראה לא צריך לדאוג לגבי זה: אתה יכול לאמת זאת לפי הערך authorization-mode (בדבר שכבר הוזכר kube-apiserver.yaml). אגב, בין המשמעויות שלו ייתכנו סוגים אחרים של הרשאה (node, webhook, always allow), אך נשאיר את שיקולם מחוץ לתחום החומר.

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

ישויות ה-API הבאות משמשות לשליטה בגישה ב-Kubernetes באמצעות RBAC:

• Role и ClusterRole - תפקידים המשמשים לתיאור זכויות גישה:
• Role מאפשר לך לתאר זכויות בתוך מרחב שמות;
• ClusterRole - בתוך האשכול, כולל לאובייקטים ספציפיים לאשכולות כגון צמתים, כתובות אתרים שאינן משאבים (כלומר, לא קשורות למשאבי Kubernetes - לדוגמה, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - משמש לכריכה Role и ClusterRole למשתמש, לקבוצת משתמשים או לחשבון שירות.

הישויות Role ו-RoleBinding מוגבלות על ידי מרחב השמות, כלומר. חייב להיות בתוך אותו מרחב שמות. עם זאת, RoleBinding יכול להתייחס ל-ClusterRole, המאפשר לך ליצור קבוצה של הרשאות כלליות ולשלוט בגישה באמצעותן.

תפקידים מתארים זכויות באמצעות מערכות כללים המכילות:

• קבוצות API - ראה תיעוד רשמי לפי apiGroups ופלט kubectl api-resources;
• משאבים (משאבים: pod, namespace, deployment וכולי.);
• פעלים (פעלים: set, update וכו.).
• שמות משאבים (resourceNames) - למקרה שבו אתה צריך לספק גישה למשאב מסוים, ולא לכל המשאבים מסוג זה.

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

דוגמאות לישויות RBAC

פשוט Role, המאפשר לקבל רשימה וסטטוס של פודים ולנטר אותם במרחב השמות target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

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

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

דוגמה RoleBinding, המאפשר למשתמש mynewuser "לקרוא" תרמילים במרחב השמות my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

ביקורת אירועים

באופן סכמטי, ניתן לייצג את ארכיטקטורת Kubernetes באופן הבא:

רכיב Kubernetes המפתח האחראי לעיבוד בקשות הוא שרת api. כל הפעולות באשכול עוברות דרכו. תוכל לקרוא עוד על מנגנונים פנימיים אלו במאמר "מה קורה ב-Kubernetes כשאתה מפעיל את kubectl run?".

ביקורת מערכות היא תכונה מעניינת ב- Kubernetes, המושבתת כברירת מחדל. זה מאפשר לך לרשום את כל השיחות ל-Kubernetes API. כפי שאתה יכול לנחש, כל הפעולות הקשורות לניטור ושינוי מצב האשכול מבוצעות באמצעות API זה. תיאור טוב של היכולות שלו ניתן (כרגיל) למצוא ב תיעוד רשמי K8s. לאחר מכן, אנסה להציג את הנושא בשפה פשוטה יותר.

לפיכך, כדי לאפשר ביקורת, עלינו להעביר שלושה פרמטרים נדרשים לקונטיינר ב-API-server, המתוארים ביתר פירוט להלן:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

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

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

אבל לא נתעכב עליהם ביתר פירוט - אתה יכול למצוא את כל הפרטים ב תיעוד kube-apiserver.

כפי שכבר צוין, כל הפרמטרים מוגדרים במניפסט עם תצורת ה-API-שרת (כברירת מחדל /etc/kubernetes/manifests/kube-apiserver.yaml), בסעיף command. נחזור ל-3 הפרמטרים הנדרשים וננתח אותם:

1. audit-policy-file - נתיב לקובץ YAML המתאר את מדיניות הביקורת. נחזור לתוכנו בהמשך, אך לעת עתה אציין שהקובץ חייב להיות קריא על ידי תהליך ה-API-server. לכן, יש צורך להרכיב אותו בתוך המיכל, עבורו אתה יכול להוסיף את הקוד הבא לקטעים המתאימים של התצורה:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - נתיב לקובץ היומן. הנתיב חייב להיות נגיש גם לתהליך שרת ה-API, אז אנו מתארים את ההרכבה שלו באותו אופן:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - פורמט יומן ביקורת. ברירת המחדל היא json, אבל פורמט הטקסט הישן זמין גם (legacy).

מדיניות ביקורת

עכשיו לגבי הקובץ המוזכר המתאר את מדיניות הרישום. הרעיון הראשון של מדיניות ביקורת הוא level, רמת רישום. הם כדלקמן:

• None - אל תירשם;
• Metadata - מטא נתונים של בקשת יומן: משתמש, זמן בקשה, משאב יעד (תרמיל, מרחב שמות וכו'), סוג פעולה (פועל) וכו';
• Request - יומן מטא נתונים וגוף הבקשה;
• RequestResponse - יומן מטא נתונים, גוף הבקשה וגוף התגובה.

שתי הרמות האחרונות (Request и RequestResponse) אין לרשום בקשות שלא ניגשו למשאבים (גישה למה שנקרא כתובות אתרים שאינן משאבים).

כמו כן כל הבקשות עוברות מספר שלבים:

• RequestReceived - השלב שבו הבקשה מתקבלת על ידי המעבד וטרם הועברה בהמשך שרשרת המעבדים;
• ResponseStarted - כותרות התגובה נשלחות, אך לפני שליחת גוף התגובה. נוצר עבור שאילתות ארוכות טווח (לדוגמה, watch);
• ResponseComplete - גוף התגובה נשלח, לא יישלח מידע נוסף;
• Panic - אירועים נוצרים כאשר מזוהה מצב חריג.

כדי לדלג על כל שלב שאתה יכול להשתמש בו omitStages.

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

הדמון kubelet עוקב אחר שינויים במניפסט עם תצורת שרת ה-API, ואם מתגלים כאלה, מפעיל מחדש את המיכל עם שרת ה-API. אבל יש פרט חשוב: שינויים בקובץ המדיניות יתעלמו על ידו. לאחר ביצוע שינויים בקובץ המדיניות, יהיה עליך להפעיל מחדש את שרת ה-API באופן ידני. מאז שרת api מופעל בתור תרמיל סטטי, צוות kubectl delete לא יגרום להפעלה מחדש. תצטרך לעשות זאת באופן ידני docker stop ב-kube-masters, שם שונתה מדיניות הביקורת:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

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

דוגמאות לפוליסות

בואו נסתכל על המבנה של קבצי מדיניות באמצעות דוגמאות.

הנה קובץ פשוט policyלרשום הכל ברמה Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

במדיניות אתה יכול לציין רשימה של משתמשים (Users и ServiceAccounts) וקבוצות משתמשים. לדוגמה, כך נתעלם ממשתמשי מערכת, אך נרשם את כל השאר ברמה Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

אפשר גם לתאר את המטרות:

• מרחבי שמות (namespaces);
• פעלים (פעלים: get, update, delete ואחרים);
• משאבים (משאבים, כמפורט להלן: pod, configmaps וכו') וקבוצות משאבים (apiGroups).

שימו לב! ניתן להשיג משאבים וקבוצות משאבים (קבוצות API, כלומר apiGroups), כמו גם את הגרסאות שלהם המותקנות באשכול, באמצעות הפקודות:

kubectl api-resources
kubectl api-versions

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

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

דוגמה טובה נוספת למדיניות ביקורת היא פרופיל בשימוש ב-GCE.

כדי להגיב במהירות לאירועי ביקורת, זה אפשרי תאר webhook. נושא זה מכוסה ב תיעוד רשמי, אשאיר אותו מחוץ לתחום המאמר הזה.

תוצאות של

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

נ.ב.

קרא גם בבלוג שלנו:

• «33+ כלי אבטחה של Kubernetes";
• «מבוא למדיניות הרשת של Kubernetes לאנשי אבטחה";
• «הבנת RBAC ב-Kubernetes";
• «9 שיטות עבודה מומלצות לאבטחת Kubernetes";
• «11 דרכים (לא) להיפרץ ב- Kubernetes".

מקור: www.habr.com