ABC of Security in Kubernetes: การพิสูจน์ตัวตน การอนุญาต การตรวจสอบ

ไม่ช้าก็เร็วในการทำงานของระบบใด ๆ ปัญหาด้านความปลอดภัยเกิดขึ้น: การรับรองความถูกต้องการแยกสิทธิ์การตรวจสอบและงานอื่น ๆ สร้างไว้แล้วสำหรับ Kubernetes โซลูชั่นมากมายซึ่งช่วยให้คุณบรรลุการปฏิบัติตามมาตรฐานแม้ในสภาพแวดล้อมที่มีความต้องการสูง... เนื้อหาเดียวกันนี้มีไว้สำหรับแง่มุมพื้นฐานของการรักษาความปลอดภัยที่ใช้งานภายในกลไกในตัวของ K8 ก่อนอื่นจะเป็นประโยชน์สำหรับผู้ที่เริ่มทำความคุ้นเคยกับ Kubernetes ซึ่งเป็นจุดเริ่มต้นในการศึกษาประเด็นด้านความปลอดภัย

การรับรอง

ผู้ใช้ใน Kubernetes มี XNUMX ประเภท:

• บัญชีบริการ — บัญชีที่จัดการโดย Kubernetes API
• ผู้ใช้ — ผู้ใช้ “ปกติ” จัดการโดยบริการภายนอกที่เป็นอิสระ

ข้อแตกต่างที่สำคัญระหว่างประเภทเหล่านี้คือสำหรับบัญชีบริการจะมีออบเจ็กต์พิเศษใน Kubernetes API (เรียกว่า - ServiceAccounts) ซึ่งเชื่อมโยงกับเนมสเปซและชุดข้อมูลการอนุญาตที่จัดเก็บไว้ในคลัสเตอร์ในอ็อบเจ็กต์ประเภทข้อมูลลับ ผู้ใช้ดังกล่าว (บัญชีบริการ) มีวัตถุประสงค์หลักเพื่อจัดการสิทธิ์การเข้าถึง Kubernetes API ของกระบวนการที่ทำงานในคลัสเตอร์ Kubernetes

ผู้ใช้ทั่วไปไม่มีรายการใน Kubernetes API: ต้องได้รับการจัดการโดยกลไกภายนอก มีไว้สำหรับบุคคลหรือกระบวนการที่อยู่นอกคลัสเตอร์

คำขอ API แต่ละรายการเชื่อมโยงกับบัญชีบริการ ผู้ใช้ หรือถือว่าไม่ระบุชื่อ

ข้อมูลการตรวจสอบผู้ใช้ประกอบด้วย:

• ชื่อผู้ใช้ — ชื่อผู้ใช้ (คำนึงถึงตัวพิมพ์เล็กและใหญ่!);
• โพสต์ - สตริงระบุตัวตนผู้ใช้ที่เครื่องอ่านได้ซึ่ง “สอดคล้องและไม่ซ้ำกันมากกว่าชื่อผู้ใช้”;
• กลุ่ม — รายชื่อกลุ่มที่ผู้ใช้อยู่
• พิเศษ — ฟิลด์เพิ่มเติมที่กลไกการอนุญาตสามารถใช้ได้

Kubernetes สามารถใช้กลไกการตรวจสอบสิทธิ์ได้จำนวนมาก: ใบรับรอง X509, โทเค็นผู้ถือ, พร็อกซีการตรวจสอบสิทธิ์, การตรวจสอบสิทธิ์พื้นฐาน HTTP การใช้กลไกเหล่านี้ทำให้คุณสามารถใช้รูปแบบการให้สิทธิ์ได้จำนวนมาก: จากไฟล์คงที่พร้อมรหัสผ่านไปจนถึง 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 และลงทะเบียนไฟล์เหล่านั้นในการกำหนดค่า โดยเพิ่มส่วนต่อท้ายให้กับชื่อของคีย์ -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 ใช้ประเภทการอนุญาตที่เรียกว่า เอแบค (การควบคุมการเข้าถึงตามคุณสมบัติ) รายละเอียดเกี่ยวกับเรื่องนี้สามารถพบได้ใน เอกสารราชการ. ปัจจุบันแนวทางนี้ถือเป็นวิธีดั้งเดิม แต่คุณยังสามารถใช้ร่วมกับการตรวจสอบสิทธิ์ประเภทอื่นๆ ได้

วิธีการแบ่งสิทธิ์การเข้าถึงคลัสเตอร์ในปัจจุบัน (และยืดหยุ่นกว่า) เรียกว่า อาร์แบค (การควบคุมการเข้าถึงตามบทบาท). ได้รับการประกาศว่ามีเสถียรภาพตั้งแต่เวอร์ชัน คูเบอร์เนเตส 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 - ภายในคลัสเตอร์ รวมถึงออบเจ็กต์เฉพาะคลัสเตอร์ เช่น โหนด, URL ที่ไม่ใช่ทรัพยากร (กล่าวคือ ไม่เกี่ยวข้องกับทรัพยากร Kubernetes - ตัวอย่างเช่น /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ใช้สำหรับผูกมัด Role и ClusterRole ให้กับผู้ใช้ กลุ่มผู้ใช้ หรือ ServiceAccount

เอนทิตี 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 นี้ คำอธิบายที่ดีเกี่ยวกับความสามารถของมัน (ตามปกติ) มีอยู่ใน เอกสารราชการ K8 ต่อไป ฉันจะพยายามนำเสนอหัวข้อในภาษาที่ง่ายกว่านี้

ดังนั้น เพื่อเปิดใช้งานการตรวจสอบเราต้องส่งพารามิเตอร์ที่จำเป็นสามรายการไปยังคอนเทนเนอร์ใน api-server ซึ่งมีการอธิบายรายละเอียดเพิ่มเติมด้านล่าง:

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

นอกจากพารามิเตอร์ที่จำเป็นทั้งสามนี้แล้ว ยังมีการตั้งค่าเพิ่มเติมอีกมากมายที่เกี่ยวข้องกับการตรวจสอบ: ตั้งแต่การหมุนเวียนบันทึกไปจนถึงคำอธิบายเว็บฮุค ตัวอย่างพารามิเตอร์การหมุนเวียนบันทึก:

• --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) ไม่บันทึกคำขอที่ไม่สามารถเข้าถึงทรัพยากร (เข้าถึงสิ่งที่เรียกว่า URL ที่ไม่ใช่ทรัพยากร)

คำขอทั้งหมดยังผ่าน หลายขั้นตอน:

• RequestReceived - ระยะที่ตัวประมวลผลได้รับคำขอและยังไม่ได้ส่งต่อไปตามสายโซ่ของตัวประมวลผล
• ResponseStarted — ส่วนหัวการตอบกลับจะถูกส่ง แต่ก่อนที่จะส่งเนื้อหาการตอบกลับ สร้างขึ้นสำหรับการสืบค้นที่ใช้เวลานาน (เช่น watch);
• ResponseComplete — ได้ส่งเนื้อหาตอบรับแล้ว จะไม่มีการส่งข้อมูลเพิ่มเติม
• Panic — เหตุการณ์จะถูกสร้างขึ้นเมื่อตรวจพบสถานการณ์ที่ผิดปกติ

หากต้องการข้ามขั้นตอนใด ๆ ที่คุณสามารถใช้ได้ omitStages.

ในไฟล์นโยบาย เราสามารถอธิบายส่วนต่างๆ ที่มีระดับการบันทึกที่แตกต่างกันได้ กฎการจับคู่แรกที่พบในคำอธิบายนโยบายจะถูกนำไปใช้

kubelet daemon จะตรวจสอบการเปลี่ยนแปลงในไฟล์ Manifest ด้วยการกำหนดค่าเซิร์ฟเวอร์ api และหากตรวจพบ ให้รีสตาร์ทคอนเทนเนอร์ด้วยเซิร์ฟเวอร์ api แต่มีรายละเอียดที่สำคัญ: การเปลี่ยนแปลงในไฟล์นโยบายจะถูกละเว้น. หลังจากทำการเปลี่ยนแปลงไฟล์นโยบาย คุณจะต้องรีสตาร์ทเซิร์ฟเวอร์ api ด้วยตนเอง เนื่องจาก api-server เริ่มต้นเป็น พ็อดคงที่, ทีม 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.

เพื่อให้สามารถตอบสนองต่อเหตุการณ์การตรวจสอบได้อย่างรวดเร็วจึงเป็นไปได้ อธิบายเว็บฮุค. ปัญหานี้ครอบคลุมอยู่ใน เอกสารราชการฉันจะปล่อยไว้นอกขอบเขตของบทความนี้

ผลของการ

บทความนี้นำเสนอภาพรวมของกลไกการรักษาความปลอดภัยขั้นพื้นฐานในคลัสเตอร์ Kubernetes ซึ่งช่วยให้คุณสามารถสร้างบัญชีผู้ใช้ส่วนบุคคล แยกสิทธิ์ และบันทึกการดำเนินการได้ ฉันหวังว่ามันจะเป็นประโยชน์กับผู้ที่เผชิญกับปัญหาดังกล่าวทั้งทางทฤษฎีหรือในทางปฏิบัติ ฉันขอแนะนำให้คุณอ่านรายการเอกสารอื่น ๆ ในหัวข้อความปลอดภัยใน Kubernetes ซึ่งมีอยู่ใน "PS" - บางทีคุณอาจพบรายละเอียดที่จำเป็นเกี่ยวกับปัญหาที่เกี่ยวข้องกับคุณในนั้น

PS

อ่านเพิ่มเติมในบล็อกของเรา:

• «เครื่องมือรักษาความปลอดภัย 33+ Kubernetes";
• «ข้อมูลเบื้องต้นเกี่ยวกับนโยบายเครือข่าย Kubernetes สำหรับผู้เชี่ยวชาญด้านความปลอดภัย";
• «ทำความเข้าใจกับ RBAC ใน Kubernetes";
• «9 แนวทางปฏิบัติที่ดีที่สุดสำหรับความปลอดภัยของ Kubernetes";
• «11 วิธีในการ (ไม่) ตกเป็นเหยื่อของการแฮ็ก Kubernetes'

ที่มา: will.com