پیکربندی

محیط

متغیر	الزامی	توضیح
RAHDAR_DB_URL	بله	jdbc:postgresql://host:5432/rahdar
RAHDAR_DB_USER / _DB_PASSWORD	بله	—
RAHDAR_SECRET_KEY	با ارائه‌دهندهٔ env	کلیدی که همهٔ رازهای ذخیره‌شده را محافظت می‌کند. Base64 از دقیقاً ۳۲ بایت، وگرنه برنامه بالا نمی‌آید: openssl rand -base64 32. برای نگه‌داشتن چند نسخه، رازها و چرخش کلید را ببینید
RAHDAR_CONFIG_ENCRYPT_KEY	خیر	مقادیر {cipher} ذخیره‌شده در rahdar_config_property را رمزگشایی می‌کند. کلیدی متفاوت از RAHDAR_SECRET_KEY — آن را دوباره استفاده نکنید
RAHDAR_PUBLIC_URL	برای کلید عبور	نشانی‌ای که مردم Rahdar را با آن باز می‌کنند، مثل https://rahdar.example.com (ویژگی rahdar.public-url؛ پیش‌تر rahdar.alerting.public-url بود). با تنظیم آن، اعلان‌های هشدار به هشدارهای همان خوشه پیوند می‌دهند. کلیدهای عبور (passkey) هم به آن وابسته‌اند: بدون آن کاربران هنوز می‌توانند از برنامهٔ احراز هویت استفاده کنند اما نه از کلید عبور، و صفحهٔ حساب این را می‌گوید. کلید عبور به میزبان آن تعلق دارد، پس تغییر میزبان (نه فقط درگاه یا مسیر) همهٔ کلیدهای عبورِ ثبت‌شده با میزبان قبلی را از کار می‌اندازد؛ کدهای بازیابی و برنامهٔ احراز هویت سالم می‌مانند. اگر مقدار آن نشانی http یا https نباشد، راه‌اندازی شکست می‌خورد
RAHDAR_IDENTITY_LOCAL_RECOVER	خیر	بازیابی اضطراری. یک نام کاربری محلی. هنگام راه‌اندازی، Rahdar آن حساب را باز می‌کند، برنامهٔ احراز هویت، کلیدهای عبور، کدهای بازیابی و دستگاه‌های مورد اعتمادش را حذف و توکن‌های API او را باطل می‌کند، در ورود بعدی تغییر گذرواژه را الزامی می‌کند، نشست‌هایش را پایان می‌دهد و کار را در مسیر ممیزی و هشدار را در گزارش می‌نویسد. وقتی تنها مدیر هم دستگاه و هم کدهای بازیابی‌اش را از دست داده از آن استفاده کنید. پس از راه‌اندازی مجدد آن را بردارید وگرنه راه‌اندازی بعدی دوباره حساب را بازیابی می‌کند؛ نام کاربری ناشناخته فقط به‌صورت خطا ثبت می‌شود و چیزی تغییر نمی‌کند. مدیر با گذرواژهٔ فعلی وارد می‌شود، گذرواژهٔ تازه می‌گذارد و یک عامل جدید ثبت می‌کند
SERVER_TOMCAT_REMOTEIP_INTERNAL_PROXIES	وقتی پروکسی معکوس بیرون از بازه‌های خصوصی است	یک عبارت باقاعده که با نشانی پروکسی‌های معکوس شما مطابقت دارد. فقط همین‌ها می‌توانند نشانی کلاینت را با X-Forwarded-For تعیین کنند؛ محدودیت‌های ورود و مسیر ممیزی از آن استفاده می‌کنند. پیش‌فرض به loopback، 10/8، 172.16/12، 192.168/16 و fc00::/7 اعتماد می‌کند. هرگز آن را خالی نگذارید: به همهٔ کلاینت‌ها اعتماد می‌شود
JAVA_OPTS	خیر	پیش‌فرض -XX:MaxRAMPercentage=50

رازها و چرخش کلید

هر رازِ ذخیره‌شده با کلید دادهٔ تصادفیِ خودش رمز می‌شود و آن کلید داده را یک کلید رمزنگاریِ کلید (KEK) نسخه‌دار می‌پیچد. رازها عبارت‌اند از اعتبارنامه‌های بروکر و پل، رازهای کانال‌های اعلان، رازهای افزونه‌ها و متن اصلیِ پیام‌های مهروموم‌شدهٔ حاکمیت. KEKها را یک ارائه‌دهندهٔ کلید فراهم می‌کند. ارائه‌دهنده یک بار در راه‌اندازی انتخاب می‌شود و جایگزینی وجود ندارد: اگر ارائه‌دهنده نتواند کلید معتبری بدهد، Rahdar بالا نمی‌آید و نام ارائه‌دهنده را می‌گوید.

ارائه‌دهنده‌ها

rahdar.secrets.provider یکی از آن‌ها را برمی‌گزیند. در متغیر محیطی، خط‌تیره و نقطه هر دو به زیرخط تبدیل می‌شوند؛ پس rahdar.secrets.vault.uri می‌شود RAHDAR_SECRETS_VAULT_URI.

ارائه‌دهنده	کلیدها کجا هستند	تنظیمات (پیش‌فرض در کروشه)
env (پیش‌فرض)	RAHDAR_SECRET_KEY: یک کلید Base64 ساده (نسخهٔ ۱)، یا 1=<b64>,2=<b64> برای چند نسخه	ندارد
file	پوشه‌ای از فایل‌هایی به نام kek-<n> (Base64 از ۳۲ بایت؛ n شمارهٔ نسخه). یک volume از Kubernetes Secret مناسب است	rahdar.secrets.file.directory
vault	HashiCorp Vault، KV نسخهٔ ۲. فیلد kek هر نسخهٔ زندهٔ KV یک نسخهٔ کلید است	rahdar.secrets.vault.uri، .mount [secret]، .path، .oidc-path [پیش‌فرض همان .path]، .authentication [token؛ یا approle، kubernetes]، .token، .role-id، .secret-id، .kubernetes-role، .kubernetes-token-path [/var/run/secrets/kubernetes.io/serviceaccount/token]
kubernetes	یک Kubernetes Secret با کلیدهای kek-<n> که از طریق API server و با service account پاد خوانده می‌شود	rahdar.secrets.kubernetes.secret-name، .namespace [namespace خودِ پاد]، .api-url [https://kubernetes.default.svc]، .token-path [/var/run/secrets/kubernetes.io/serviceaccount/token]، .ca-path [/var/run/secrets/kubernetes.io/serviceaccount/ca.crt]

service account ارائه‌دهندهٔ kubernetes روی همان یک Secret به دسترسی get نیاز دارد.

هر کلید باید Base64 از دقیقاً ۳۲ بایت باشد. نسخهٔ کلید همان عددِ نامش است (kek-2، یا 2= در متغیر محیطی، یا نسخهٔ KV در Vault).

Vault به‌طور پیش‌فرض نسخه‌های کمی نگه می‌دارد

KV نسخهٔ ۲ به‌طور پیش‌فرض فقط ۱۰ نسخه نگه می‌دارد و با نوشتن نسخهٔ یازدهم قدیمی‌ترین را پاک می‌کند؛ هر نوشتنی حساب می‌شود، حتی اگر فقط oidc-client-secret را عوض کند. از دست رفتن نسخه‌ای که هنوز رازهایی زیر آن بسته شده‌اند، آن رازها را ناخوانا می‌کند. بنابراین:

• max_versions را روی آن مسیر بالا بگذارید (برای نمونه vault kv metadata put -max-versions=0 secret/rahdar؛ 0 یعنی بی‌حد).
• oidc-client-secret را با rahdar.secrets.vault.oidc-path در مسیر جدایی نگه دارید تا ویرایش آن نسخه‌ای به مسیر کلیدها اضافه نکند.
• نسخه‌ای را که هنوز در کار است هرگز پاک یا نابود نکنید. اگر رازهایی از نسخه‌ای استفاده کنند که ارائه‌دهنده دیگر ندارد، تنظیمات ← امنیت آن را «گم‌شده» نشان می‌دهد و در گزارش هشداری با شمارهٔ نسخه و تعداد ثبت می‌شود.

رازِ کلاینت OIDC

ارائه‌دهنده رازِ کلاینت OIDC را هم با نام oidc-client-secret می‌دهد: کلیدی با همین نام در فایل یا Kubernetes Secret، فیلد oidc-client-secret در آخرین نسخهٔ .oidc-path در Vault، یا RAHDAR_OIDC_CLIENT_SECRET با ارائه‌دهندهٔ env. آن را فقط همین‌جا تنظیم کنید: وقتی ارائه‌دهنده env نیست، رازِ کلاینتی که در تنظیمات OIDC خودِ Rahdar داده شود خطا می‌دهد.

چرخاندن کلید

چرخش برخط است: همهٔ رازها را بدون وقفه به نسخهٔ جدید کلید می‌برد و هیچ‌گاه رازی را به‌صورت آشکار نمی‌خواند.

1. یک نسخهٔ جدید به ارائه‌دهنده اضافه کنید (kek-2، 1=…,2=…، یا نسخهٔ جدید KV). نسخهٔ قدیمی را نگه دارید.
2. در تنظیمات ← امنیت گزینهٔ چرخاندن کلید را بزنید. مجوز settings:write و یک ورود اخیر لازم است. معادلش POST /api/v1/settings/secrets/rotations است.
3. رازهای جدید بلافاصله نسخهٔ جدید را به کار می‌برند و یک کار پس‌زمینه بقیه را دسته‌دسته دوباره می‌پیچد. چرخش را تا رسیدن به Succeeded دنبال کنید: پس از شروع دست‌کم ۳۰ ثانیه صبر می‌کند تا هر نسخهٔ در حال اجرا از نسخهٔ جدید خبردار شود، و راه‌اندازی مجدد Rahdar در این بین بی‌خطر است.
4. کلید قدیمی را فقط پس از آن از ارائه‌دهنده بردارید. امنیت تعداد ردیف‌های هر نسخه را می‌شمارد، پس می‌بینید یک نسخهٔ قدیمی کی دیگر استفاده نمی‌شود.

اگر چرخش شکست بخورد (خطایش انبار و ردیف را نام می‌برد)، کلیدهای قدیمی را در ارائه‌دهنده نگه دارید، علت را رفع کنید و دوباره شروعش کنید: فقط آنچه هنوز زیر نسخهٔ قدیمی است دوباره پیچیده می‌شود. برداشتن زودهنگام کلید قدیمی رازهای زیرِ آن را ناخواندنی می‌کند و تنها راه بازگشت، وارد کردن دوبارهٔ آن‌هاست.

تعویض ارائه‌دهنده

1. کلید فعلی را با شمارهٔ نسخه‌ای دست‌کم برابر نسخهٔ فعلی در ارائه‌دهندهٔ جدید بگذارید.
2. rahdar.secrets.provider (و تنظیماتش) را عوض و راه‌اندازی مجدد کنید. Rahdar فقط وقتی بالا می‌آید که ارائه‌دهندهٔ جدید نسخهٔ فعلی را داشته باشد.
3. یک نسخهٔ جدیدتر به ارائه‌دهندهٔ جدید اضافه کنید و مثل بالا به آن بچرخید. تازه بعد از آن ارائه‌دهندهٔ قدیمی را کنار بگذارید.

ارتقا از نسخه‌های قبلی

رازهایی که نسخه‌های قبلی ذخیره کرده‌اند در اولین راه‌اندازی حذف می‌شوند، چون قالب ذخیره‌سازی عوض شده است. اعتبارنامه‌های بروکر (خوشه‌ها و پل‌ها)، رازهای کانال‌های اعلان و رازهای افزونه‌ها را دوباره وارد کنید. متن اصلیِ پیام‌هایی که پیشتر مهروموم شده‌اند دیگر در دسترس نیست. چیز دیگری از دست نمی‌رود.

پنهان‌سازی

رمز عبور، توکن، کلید API، مقدار Bearer، اطلاعات کاربر در URL و کلیدهای خصوصی در لاگ‌ها، پارامترهای ممیزی، پاسخ‌های خطا و خروجی broker.xml با [redacted] پوشانده می‌شوند، حتی اگر رازی از مسیری برسد که Rahdar انتظارش را نداشت. Rahdar فقط روی کنسول لاگ می‌نویسد.

دو صفحه

پیکربندی عمداً به دو نیم تقسیم شده و ملاک تقسیم این است که چه کسی و چه زمانی یک مقدار را تغییر می‌دهد.

صفحهٔ اپراتور — rahdar_setting — چیزی را نگه می‌دارد که اپراتور حین اجرای Rahdar تنظیم می‌کند: آهنگ poll، پنجره‌های نگهداری، سقف عملیات انبوه، و سقف هزینهٔ کنسول SQL. تغییرات بی‌درنگ اثر می‌کنند، ممیزی می‌شوند و نیازی به restart ندارند. هر زمان‌بندیِ قابل تنظیم از طریق settings یک trigger بازخوان است، نه یک annotation ثابت؛ به همین دلیل تغییر آهنگ فوری است.

صفحهٔ استقرار — ویژگی‌های bootstrap اسپرینگ کلاود — چیزی را نگه می‌دارد که به خودِ استقرار تعلق دارد: datasource، کلیدها، و issuer مربوط به OIDC. مقادیر اینجا می‌توانند به‌صورت {cipher} ذخیره و با RAHDAR_CONFIG_ENCRYPT_KEY رمزگشایی شوند. هیچ config server ای در کار نیست.

برای چراییِ آن ADR-0047 و برای اینکه یک زمان‌بندی چگونه تغییر تنظیمات را برمی‌دارد ADR-0048 را ببینید (انگلیسی).

ورود و نشست‌ها

زیر تنظیمات ← نشست‌ها و تنظیمات ← ورود با گذرواژه، بدون restart:

تنظیم	کلید	پیش‌فرض	معنا
مهلت بی‌کاری	security.session.idle-timeout	30m	نشست چه مدت می‌تواند بدون هیچ کاری از سوی کاربر بماند. فقط درخواست‌هایی که چیزی را تغییر می‌دهند و درخواست‌هایی که کنسول ظرف یک دقیقه پس از کلیک یا فشردن کلید می‌فرستد به‌حساب می‌آیند؛ poll و جریان زنده نه، پس تبی که رها شده از حساب خارج می‌شود. اسکریپتی که باید وارد بماند X-Rahdar-Activity: 1 می‌فرستد
حداکثر عمر نشست	security.session.absolute-lifetime	12h	نشست چه مدت پس از ورود، هر قدر هم فعال باشد، پایان می‌یابد
حداقل طول گذرواژه	identity-local.password.min-length	12	کمترین تعداد نویسه‌ای که یک گذرواژهٔ محلی جدید باید داشته باشد
بررسی گذرواژه‌های لورفته	identity-local.password.breach-lookup	خاموش	یک کلید. با روشن‌بودن، گذرواژهٔ محلی جدید با سرویس برخط گذرواژه‌های لورفته هم سنجیده می‌شود: فقط پنج نویسهٔ نخست SHA-1 آن از Rahdar بیرون می‌رود و اگر جست‌وجو شکست بخورد گذرواژه پذیرفته می‌شود. فهرست برون‌خطِ ۱۰۰٬۰۰۰ گذرواژهٔ رایج همیشه به‌کار می‌رود
مدت اعتماد به دستگاه	identity-local.mfa.trusted-device-lifetime	30d	کاربر پس از ارائهٔ عامل دوم هنگام ورود می‌تواند به آن مرورگر اعتماد کند: در این مدت ورود از آن مرورگر فقط گذرواژه می‌خواهد. مقدار 0 دستگاه‌های مورد اعتماد را خاموش می‌کند: گزینه نمایش داده نمی‌شود و دستگاه‌های موجود نادیده گرفته می‌شوند. کارهایی که تأیید دوبارهٔ هویت می‌خواهند همچنان عامل دوم را لازم دارند و اگر حساب به‌خاطر شکست‌های ورود از جای دیگر قفل شده باشد، صاحبش همچنان می‌تواند از دستگاه مورد اعتماد وارد شود. تغییر گذرواژه، بازنشانی عامل‌های حساب و غیرفعال‌کردن آن، دستگاه‌های مورد اعتماد را لغو می‌کند

مدت‌زمان به‌شکل 30m، 12h یا ISO-8601 (PT30M) نوشته می‌شود. کاربر می‌تواند زیر حساب ← نشست‌ها ببیند کجا وارد شده و هر یک از آن نشست‌ها را پایان دهد؛ مدیر همین کار را برای هر کاربر از مدیریت ← کاربران ← نشست‌ها انجام می‌دهد. ADR-0145 را ببینید (انگلیسی).

پایگاه‌داده

PostgreSQL، با شمایی که در اختیار Liquibase است و در زمان راه‌اندازی مهاجرت می‌شود. Rahdar در بوت، نگاشت را در برابر شمای مهاجرت‌شده اعتبارسنجی می‌کند و DDL تولید نمی‌کند؛ پس شمایی که drift کرده با صدای بلند شکست می‌خورد، نه در سکوت.

Postgres مالک پیکربندی، کاربران و مسیر ممیزی است. جدول‌های برآمده از بروکر — queue_snapshot و metric_sample — یک کش دورانداختنی هستند: از دست دادنشان تاریخچه را می‌گیرد، هرگز حقیقت را نه.

اتصال‌های بروکر

از طریق رابط کاربری ثبت می‌شوند، نه از طریق محیط. هر اتصال یک endpoint مدیریتی seed و اعتبارنامه‌ها را رمزنگاری‌شده ذخیره می‌کند. انتقال اصلی Jolokia روی HTTP است؛ کلاینت Core آرتمیس کانال دومی است برای اعلان‌ها و ورودی/خروجی وفادارانهٔ پیام، و قابلیت‌هایی که به آن نیاز دارند بر پایهٔ در دسترس بودنش گیت می‌شوند — به‌شکل قابل‌مشاهده، همراه با broker.xml ای که آن را فعال می‌کند.

ADR-0002 را ببینید (انگلیسی).