הגדרת מדיניות הרשאות ב-sidecars ב-GKE

בדף הזה מוסבר איך להגדיר סוגים שונים של כללי מדיניות הרשאה ב-sidecars של Cloud Service Mesh ב-GKE.

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

אתם צריכים להכיר את Gateway API ואת התוספים שמפנים לבדיקת הרשאות.

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

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Network Security, Network Services APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Network Security, Network Services APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    8.

‫AuthzPolicy ברמת מרחב השמות

אם רוצים לדחות דפוס תנועה צפוי לכל מרחב השמות, מגדירים מדיניות הרשאה לדחיית כל בקשות ה-HTTP הנכנסות לכל עומסי העבודה במרחב השמות:

cat >ns-authz-policy-deny.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-deny.yaml

הערך הריק selector: {} מטרגט את כל ה-Pods במרחב השמות.

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

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-allow.yaml

הערך הריק selector: {} מטרגט את כל ה-Pods במרחב השמות.

דחיית בקשות נכנסות לעומס עבודה

אם יש לכם עומס עבודה שאמור לבצע רק שיחות יוצאות, כמו משימת cron, הגדירו מדיניות הרשאה שתדחה כל בקשת HTTP נכנסת לעומס העבודה:

cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f deny-path-authz-policy.yaml

הפלט אמור להיראות כך:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

אחרי שמחילים את המדיניות הזו, כל בקשת HTTP נכנסת לנתיב /deny_path בפודים שתואמים לאפליקציה: EXAMPLE_APP תידחה, והגורם ששלח את הקריאה יקבל קוד תגובה HTTP 403 Forbidden.

אישור בקשות נכנסות ספציפיות לעומס עבודה (workload)

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

בדוגמה הבאה מוגדרת מדיניות הרשאה בפריסה של example-app, שמאפשרת רק בקשות mTLS מפודים עם הזהות spiffe://cluster.local/NAMESPACE/pod1.

cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f allow-authz-policy.yaml

הפלט אמור להיראות כך:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

רק בקשות נכנסות שאומתו באמצעות mTLS ומציגות את זהות SPIFFE המדויקת spiffe://cluster.local/NAMESPACE/pod1 יקבלו את התגובה HTTP 200 OK. כל בקשה אחרת תידחה על ידי שרת ה-proxy עם שגיאת HTTP 403 Forbidden.

העברה למנוע הרשאות חיצוני

אתם יכולים להביא מנוע הרשאות משלכם ולהגדיר את Cloud Service Mesh כך שיקצה את כל החלטות ההרשאה של עומס עבודה למנוע שהוגדר.

  1. מתקינים את ה-CRD של GCPAuthzExtension אם הוא עדיין לא מותקן:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/main/config/crd/networking.gke.io_gcpauthzextensions.yaml

  2. פורסים עומס עבודה של תוסף שמפנה לבדיקת הרשאות מבוסס-הודעות ב-Kubernetes שתומך בפרוטוקול gRPC של ext_proc, ומגדירים משאב של תוסף שמפנה לבדיקת הרשאות:

    cat >authz-extension.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzExtension
metadata:
  name: my-authz-ext
  namespace: NAMESPACE
spec:
  backendRef:
    group: ""
    kind: Service
    name: authz-service
    port: PORT
  authority: "authz-service.NAMESPACE.svc.cluster.local"
  forwardHeaders:
  - Authorization
  failOpen: false
  timeout: "100ms"
  wireFormat: ExtProcGRPC
EOF
kubectl apply -f authz-extension.yaml

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

    • ‫NAMESPACE: מרחב השמות של שירות authz-service ועומסי העבודה.
    • ‫PORT: היציאה של שירות authz-service שמשרת את ה-API של ext_proc gRPC.

    הפקודה הזו יוצרת תוסף שמפנה לבדיקת הרשאות מבוסס-קריאה חוזרת, שפועל כשירות Kubernetes‏ authz-service.

    הפלט אמור להיראות כך:

    gcpauthzextension.networking.gke.io/my-authz-ext created

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

    cat >authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
    to:
      operations:
      - paths:
        - type: Exact
          value: "/api/payments-schedule"
  action: CUSTOM
  enforcementLevel: L7
  customProviders:
    extensionRefs:
    - group: networking.gke.io
      kind: GCPAuthzExtension
      name: my-authz-ext
EOF
kubectl apply -f authz-policy.yaml

    הפלט אמור להיראות כך:

    gcpauthzpolicy.networking.gke.io/my-workload-authz created

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