سیاست به عنوان کد (PAC) یک رویکرد توسعه نرم افزار است که سیاست های مجوز را به عنوان کد در نظر می گیرد. این بدان معنی است که خط مشی ها در یک زبان برنامه نویسی مانند Rego یا Cedar نوشته می شوند و در یک سیستم کنترل نسخه در کنار بقیه کدها ذخیره می شوند.
این وبلاگ در مورد مزایای PAC بحث می کند و عمیق تر به تفاوت بین دو زبان محبوب PAC می پردازد: Rego، زبان موتور سیاست باز (OPA)، یک پروژه CNCF و سدر – زبانی که توسط Amazon Verified Permissions (AVP) استفاده می شود، سرویسی که مجوز دقیقی را برای منابع AWS فراهم می کند.
مزایای استفاده از PAC:
-
سیاست جداسازی از کد: PAC به شما امکان می دهد تا خط مشی را از کد جدا کنید، که مدیریت و به روز رسانی سیاست ها را آسان تر می کند.
-
افزایش انعطاف پذیری: PAC به شما انعطاف بیشتری در نحوه تعریف سیاست ها می دهد و به شما امکان می دهد از انواع ساختارهای برنامه نویسی برای ایجاد سیاست های پیچیده استفاده کنید.
-
عملکرد بهبود یافته: PAC می تواند عملکرد را با بارگذاری ارزیابی خط مشی از برنامه کاربردی به موتور خط مشی اختصاصی بهبود بخشد.
Rego و Cedar چه چیزی مشترک دارند؟
-
هر دو منبع باز هستند.
-
هر دو خط مشی به عنوان کد هستند.
-
هر دو بر جداسازی سیاست از کد تمرکز دارند.
-
هر دو زبان همه منظوره و موتورهای تصمیم گیری هستند.
-
هر دو بر عملکرد و قابلیت حسابرسی متمرکز هستند.
-
هر دو با اجرای موتور سیاست در سرویس مصرف کننده یا نزدیک به آن، تاخیر کم را فعال می کنند.
-
هر دو زبان برنامه نویسی منطقی هستند.
-
هر دو را می توان در مقیاس با اوپال.
تفاوت های کلیدی چیست؟
-
منطقه تمرکز: OPA یک پروژه CNCF است و بیشتر برای کنترل دسترسی در سطح زیرساخت (سرویس به سرویس، کنترل پذیرش در K8s) استفاده می شود. Cedar بر مجوز در سطح برنامه متمرکز است.
-
زبان:
Rego یک مشتق Datalog / Prolog است. در حالی که Cedar یک زبان برنامه نویسی منطقی است، اما ترجیح می دهد به نفع تمرکز بیشتر دامنه خاص، کمتر عمومی باشد.
-
خوانایی:
سدر از Rego خواناتر است. Cedar دقیق‌تر تایپ می‌شود، و تمرکز بیشتری روی خوانایی نسبت به Rego دارد، با کد اصلی Cedar که احتمالاً برای افراد غیر عادی خوانا است (به لطف ساختار نظر واضح آن)، برخلاف کد Rego که خواندن آن می‌تواند بسیار پیچیده باشد.
-
ابزارها و ماژول ها:
Rego ابزارهای داخلی زیادی دارد که می‌توان از آنها برای انجام کارهایی مانند تجزیه GraphQL، JSON Web Tokens، جستجوی نمودار JSON و موارد دیگر استفاده کرد. در حال حاضر، Cedar چنین ابزارهای داخلی را شامل نمی شود، و هدف آن مدلی بیشتر از زبان خالص است.
-
چارچوب های زیربنایی:
OPA و Rego مبتنی بر Go هستند و به طور بومی از کامپایل برای اسمبلی وب پشتیبانی می کنند، در حالی که Cedar مبتنی بر Rust است. اینها تفاوت های چشمگیری نیستند، اما اگر به دنبال جاسازی یا گسترش زبان ها با سایر کدهای Go یا Rust هستید، می توانند مرتبط باشند.
-
جامعه و اکوسیستم:
OPA یک پروژه CNCF است، با یک جامعه بزرگ (البته نه چندان باز – به دلیل درگیری با Styra، شرکت پشتیبان OPA). سرو دارای یک جامعه کوچک شکوفا و پشتیبانی AWS – به دلیل قدرتش در ایجاد استانداردهای بومی ابری به تنهایی شناخته شده است.
-
دویدن و تست کردن:
Rego را می توان به عنوان بخشی از Go SDK، CLI، به عنوان یک عامل شبح با OPA اجرا کرد، و می توان آن را به عنوان یک افزونه در بسیاری از ابزارهای رایج (به عنوان مثال Gatekeeper، Confest، Envoy، Kong)، Cedar به عنوان Rust SDK، CLI، و از طریق Cedar-agent به عنوان یک شبح مستقل اجرا کرد.
-
مدیریت داده ها:
داده های خط مشی پایه به راحتی در هر دو موتور به عنوان بخشی از کد نگاشت می شوند و در Cedar تا حدودی ساختارمندتر هستند. هر دو موتور همچنین از بارگذاری داده های پویا پشتیبانی می کنند. Rego با اسناد JSON عمومی که تحت آرگومان های سطح بالا نقشه برداری شده اند کار می کند
input(برای درخواست های دریافتی) وdata(در حافظه ذخیره). Cedar همچنین از اسناد JSON مانند، که به عنوان “برش نهاد” نامیده می شود، برای ورودی استفاده می کند. اینها به‌طور خودکار در موجودیت‌ها (یعنی اصول، منابع و گروه‌ها) نگاشت می‌شوند – به این ترتیب Cedar، برخلاف Rego، یک قالب خاص برای JSON ورودی انتظار دارد.
داده های درون حافظه / حافظه پنهان در Cedar فقط به عنوان بخشی از عامل Cedar پشتیبانی می شود.
هر دو موتور توسط اوپال که می تواند هر دو موتور را با خط مشی و داده در زمان واقعی مدیریت کند (و حتی آنها را در کنار هم اجرا کند)
مزایا و معایب Cedar / Rego – خلاصه ای سریع
رگو
-
طرفداران:
- به طور گسترده استفاده می شود و پشتیبانی می شود
- یک اکوسیستم بالغ از ابزارها و ماژول ها
- زبان منعطف و رسا
-
معایب:
- یادگیری می تواند پیچیده و دشوار باشد
- به اندازه Cedar قابل خواندن نیست (مخصوصاً برای اعضای تیم غیر فنی)
-
عمومی:
- زیرساخت بیشتر و K8 گرا
سدر
-
طرفداران:
- خواناتر از Rego
- زبان ساختارمندتر
- با پشتیبانی AWS
-
معایب:
- در حال حاضر، به اندازه Rego استفاده یا پشتیبانی نمی شود
- اکوسیستم کوچکتری از ابزارها و ماژول ها
-
عمومی:
- بیشتر مجوزهای برنامه گرا
بیایید به چند کد نگاه کنیم
در زیر یک RBAC+مالکیت ساده (با نام مستعار light ABAC) در هر دو زبان آورده شده است.
رگو
package play
import future.keywords.if
default allow := false
allow if permit(input.principal, input.action, input.resource)
permit("alice", "read", "document") if input.resource_owner == input.principal
سدر
permit(
principal == User::"alice",
action == Action::"read",
resource == Document::"document"
) when {
resource.owner == principal
}
همانطور که می بینید، این دو خط مشی بسیار شبیه به هم هستند و هر دو زبان را می توان اظهاری در نظر گرفت. تفاوت اصلی این است که خط مشی Rego از یک نحو ساده تر و عمومی تر استفاده می کند، در حالی که خط مشی Cedar از نحو دقیق تری استفاده می کند – که وضوح را حتی برای خوانندگان غیر فنی می افزاید (با ساختار “مجوز / زمانی که، مگر” و کلمات کلیدی (مانند اصلی، عمل، منبع))
خلاصه: کدام را انتخاب کنیم؟
به طور خلاصه، Rego و Cedar زبان‌ها و موتورهای قدرتمند سیاست به‌عنوان کد با ویژگی‌های متمایز هستند. در حالی که آنها ویژگی های مشترکی دارند، مانند منبع باز بودن، جداسازی خط مشی از کد، و تمرکز بر عملکرد و قابلیت حسابرسی، اما در حوزه تمرکز، طراحی زبان، ابزارها و ماژول های موجود و زیرساخت های زیربنایی متفاوت هستند.
هر دو زبان دارای منحنی یادگیری شدید و پیچیدگی مرتبط با آنها هستند. برای ساده‌سازی فرآیند پذیرش اولیه، ابزارهایی مانند Permit.io می‌توانند مفید باشند. Permit.io یک راه حل رابط کاربری کم کد برای تولید کد Rego یا Cedar ارائه می دهد که به توسعه دهندگان (و ذینفعان غیر فنی) امکان می دهد سریعتر شروع کنند و بر چالش های اولیه این زبان ها غلبه کنند.
در نهایت، انتخاب بین Rego و Cedar به مورد استفاده و الزامات خاص بستگی دارد، در حالی که استفاده از ابزارهای تولید کد می‌تواند پذیرش سریعتر و انعطاف‌پذیری آسان‌تر را در جابجایی یا ترکیب این دو فراهم کند. پس شاید شما مجبور به انتخاب نباشید.
