تعيين أذونات للموارد في حزم أصول Databricks

توضح هذه المقالة كيفية تعيين أذونات لمهام Azure Databricks وخطوط أنابيب Delta Live Tables وMLOps Stacks في حزم أصول Databricks. راجع ما هي حزم أصول Databricks؟.

في ملفات تكوين حزمة Azure Databricks، يمكنك تحديد الأذونات لتطبيقها على جميع الموارد المعرفة في المجموعة، أو يمكنك تحديد أذونات واحدة أو أكثر لتطبيقها على موارد معينة.

تعريف الأذونات لتطبيقها على جميع الموارد

يمكنك تحديد الأذونات لتطبيقها على جميع التجارب والوظائف والنماذج والتدفقات المحددة في resources استخدام تعيين المستوى permissions الأعلى. راجع الأذونات.

توصي Databricks بهذا الأسلوب لإدارة أذونات موارد Databricks Asset Bundles.

تعريف الأذونات لمورد معين

يمكنك استخدام permissions التعيين في تجربة أو مهمة أو نموذج أو تعريف مسار في resources لتحديد أذونات واحدة أو أكثر لهذا المورد.

يجب أن يتضمن كل إذن في permissions التعيين التعيينين التاليين:

• إما user_name، group_nameأو service_principal_name، باسم المستخدم أو المجموعة أو كيان الخدمة، على التوالي.
• level، باسم مستوى الأذونات. مستويات الأذونات المسموح بها لكل مورد هي التالية:
  • التجارب: CAN_EDITوCAN_MANAGE.CAN_READ
  • الوظائف: CAN_MANAGEو CAN_MANAGE_RUNCAN_VIEWو و.IS_OWNER
  • النماذج: CAN_EDITو CAN_MANAGECAN_MANAGE_STAGING_VERSIONSوCAN_MANAGE_PRODUCTION_VERSIONS.CAN_READ
  • البنية الأساسية لبرنامج ربط العمليات التجارية: CAN_MANAGEو CAN_RUNCAN_VIEWو و.IS_OWNER

للحصول على معلومات حول مستويات أذونات محددة، راجع:

• التجارب: قوائم التحكم في الوصول لتجربة MLflow
• الوظائف: قوائم ACL للوظيفة
• النماذج: قوائم ACL لنموذج MLflow
• البنية الأساسية لبرنامج ربط العمليات التجارية: Delta Live Tables ACLs

يوضح بناء الجملة التالي كيفية الإعلان عن أذونات متعددة لكل نوع مورد، إما في تعيين المستوى resources الأعلى أو resources تعيين داخل هدف (تشير علامات الحذف إلى محتوى محذف، للإيجاز):

# ...
resources:
  experiments:
    <some-programmatic-identifier-for-this-experiment>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  jobs:
    <some-programmatic-identifier-for-this-job>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  models:
    <some-programmatic-identifier-for-this-model>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  pipelines:
    <some-programmatic-identifier-for-this-pipeline>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name-1> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...

targets:
  <some-programmatic-identifier-for-this-target>:
    resources:
      experiments:
        <some-programmatic-identifier-for-this-experiment>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      jobs:
        <some-programmatic-identifier-for-this-job>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      models:
        <some-programmatic-identifier-for-this-model>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      pipelines:
        <some-programmatic-identifier-for-this-pipeline>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
    # ...

يتم دمج أي أذونات تم الإعلان عنها لمورد في تعيين المستوى resources الأعلى مع أي أذونات تم الإعلان عنها لنفس resources التعيين في هدف فردي. على سبيل المثال، بالنظر إلى التعيين التالي resources لنفس المورد في كل من المستوى الأعلى وفي الهدف (تشير علامات الحذف إلى محتوى محذف، للإيجاز):

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - user_name: someone@example.com
          level: CAN_VIEW
      # ...

targets:
  dev:
    # ...
    resources:
      jobs:
        my-job:
          # ...
          permissions:
            - user_name: someone@example.com
              level: CAN_RUN
          # ...

عند تشغيل databricks bundle validate هذا المثال، يكون الرسم البياني الناتج كما يلي (تشير علامات الحذف إلى محتوى محذف، للإيجاز):

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "permissions": [
          {
            "level": "CAN_VIEW",
            "user_name": "someone@example.com"
          },
          {
            "level": "CAN_RUN",
            "user_name": "someone@example.com"
          }
        ],
        "...": "..."
      }
    }
  }
}