هشدار: از آنجا که نشانه ها مقادیر مات تلقی می شوند ، ساختار آنها بدون مستند و در معرض تغییر است. به همین دلایل ، ما استفاده از نشانه های موجود در اسکریپت های شما یا اتوماسیون را توصیه نمی کنیم زیرا این امر می تواند باعث شکستگی شود.
توکن ها روش اصلی تأیید اعتبار در طاق هستند. از توکن ها می توان به طور مستقیم استفاده کرد یا از روشهای AUT می توان برای تولید پویا توکن بر اساس هویت های خارجی استفاده کرد.
اگر راهنمای شروع کار را پشت سر گذاشته اید ، احتمالاً متوجه شده اید که سرور Vaul t-Dev (یا اپراتور طاق برای یک سرور غیر DEV) یک "نشانه اصلی" را آغاز می کند. این اولین روش تأیید اعتبار برای طاق است. این همچنین تنها روش AUTH است که نمی تواند غیرفعال شود.
همانطور که در مفاهیم احراز هویت بیان شده است ، تمام مکانیسم های احراز هویت خارجی ، مانند GitHub ، نقشه ها را به صورت پویا ایجاد می کنند. این نشانه ها دارای تمام خصوصیات مشابه یک نشانه دستی طبیعی هستند.
در داخل طاق ، توکن ها به اطلاعات. مهمترین اطلاعاتی که به یک نشانه نقشه برداری می شود ، مجموعه ای از یک یا چند سیاست پیوست است. این سیاستها آنچه را که دارنده نشانه مجاز به انجام آن در طاق است ، کنترل می کند. سایر اطلاعات نقشه برداری شده شامل ابرداده ای است که می توان آنها را مشاهده کرد و به پرونده حسابرسی مانند زمان ایجاد ، آخرین زمان تجدید و موارد دیگر اضافه می شود.
برای شیرجه عمیق تر به مفاهیم نشانه بخوانید. برای جزئیات بیشتر در مورد نحوه عملکرد این مفاهیم در عمل ، به آموزش توکن ها مراجعه کنید.
از طاق 1. 0 ، دو نوع نشانه وجود دارد: نشانه های سرویس و نشانه های دسته ای. بخشی در نزدیکی پایین این صفحه حاوی اطلاعات مفصلی در مورد تفاوت های آنها است ، اما ابتدا درک سایر مفاهیم نشانه ها مفید است. ویژگی های بخش های بعدی همه در مورد نشانه های سرویس اعمال می شود و کاربرد آنها در توکن های دسته ای بعداً مورد بحث قرار می گیرد.
فروشگاه توکن
غالباً در مستندات یا در کانال های کمک ، "فروشگاه توکن" ارجاع می شود. این همان پشتیبان تأیید هویت توکن است. این یک باطن خاص است زیرا مسئولیت ایجاد و ذخیره نشانه ها را بر عهده دارد و نمی تواند غیرفعال شود. این همچنین تنها روش AUTH است که هیچ توانایی ورود به سیستم ندارد - همه اقدامات به نشانه های معتبر موجود نیاز دارند.
نشانه های ریشه نشانه هایی هستند که خط مشی ریشه به آنها متصل هستند. نشانه های ریشه می توانند هر کاری را در طاق انجام دهند. هر چیزی . علاوه بر این ، آنها تنها نوع نشانه ای در طاق هستند که می توان بدون هیچ گونه تمدیدی که لازم نیست منقضی شود. در نتیجه ، ایجاد نشانه های ریشه به طور هدفمند دشوار است. در حقیقت فقط سه روش برای ایجاد نشانه های ریشه وجود دارد:
- توکن ریشه اولیه تولید شده در زمان آغازین اپراتور خزانه -- این توکن منقضی نمی شود
- با استفاده از یک نشانه ریشه دیگر؛یک توکن ریشه با انقضا نمی تواند توکن ریشه ای ایجاد کند که هرگز منقضی نمی شود
- با استفاده از عملگر خزانه Gener-Root (مثال) با اجازه نصابی از دارندگان کلید unseal
توکن های ریشه در توسعه مفید هستند اما باید در تولید با دقت بسیار محافظت شوند. در واقع، تیم Vault توصیه می‌کند که توکن‌های ریشه فقط برای راه‌اندازی اولیه کافی (معمولاً تنظیم روش‌ها و خط‌مشی‌های احراز هویت لازم برای اجازه دادن به مدیران برای دستیابی به توکن‌های محدودتر) یا در مواقع اضطراری استفاده شوند و بلافاصله پس از عدم استفاده از آنها لغو شوند. مورد نیاز است. اگر به یک نشانه ریشه جدید نیاز باشد، فرمان تولید ریشه اپراتور و نقطه پایانی API مربوطه می‌تواند برای تولید یک توکن در لحظه استفاده شود.
همچنین این عمل امنیتی خوبی است که هر زمان که یک توکن ریشه فعال است، چندین چشم روی یک ترمینال وجود داشته باشد. به این ترتیب افراد متعددی می‌توانند کارهای انجام شده با توکن ریشه را تأیید کنند و این توکن بلافاصله پس از تکمیل این کارها لغو شده است.
سلسله مراتب توکن و نشانه های یتیم
به طور معمول، هنگامی که یک دارنده توکن توکن‌های جدیدی ایجاد می‌کند، این توکن‌ها به‌عنوان فرزندان توکن اصلی ایجاد می‌شوند. نشانه هایی که ایجاد می کنند فرزندان آنها خواهند بود. و غیرههنگامی که یک توکن والد باطل می شود، تمام توکن های فرزند آن - و تمام اجاره نامه های آنها - نیز باطل می شوند. این تضمین می‌کند که کاربر نمی‌تواند با ایجاد یک درخت بی‌پایان از نشانه‌های فرزند، از ابطال فرار کند.
اغلب این رفتار مطلوب نیست، بنابراین کاربران با دسترسی مناسب می توانند توکن های یتیم ایجاد کنند. این نشانه ها پدر و مادر ندارند -- آنها ریشه درخت نشانه خودشان هستند. این نشانه های یتیم را می توان ایجاد کرد:
- از طریق دسترسی نوشتن به نقطه پایانی auth/token/create-orphan
- با داشتن دسترسی sudo یا root به auth/token/create و تنظیم پارامتر no_parent روی true
- از طریق نقش های فروشگاه نشانه
- با ورود به سیستم با هر روش دیگر (غیر رمزی) auth
کاربران با مجوزهای مناسب همچنین می توانند از نقطه پایانی auth/token/revoke-orphan استفاده کنند، که نشانه داده شده را باطل می کند اما به جای لغو بقیه درخت، در عوض فرزندان فوری توکن ها را یتیم می کند. با احتیاط استفاده کنید!
هنگامی که توکن ها ایجاد می شوند، یک دسترسی توکن نیز ایجاد و برگردانده می شود. این دسترسی، مقداری است که به عنوان مرجع یک نشانه عمل می کند و تنها می تواند برای انجام اقدامات محدود استفاده شود:
- ویژگی های یک توکن را جستجو کنید (بدون احتساب شناسه رمز واقعی)
- قابلیت های یک نشانه را در یک مسیر جستجو کنید
- توکن را تمدید کنید
- رمز را باطل کنید
رمزی که تماس برقرار می کند، نه نشانه مرتبط با دسترسی، باید مجوزهای مناسبی برای این عملکردها داشته باشد.
گردش کار مفید زیادی در مورد دسترسی های توکن وجود دارد. به عنوان مثال، سرویسی که از طرف یک سرویس دیگر (مانند زمانبندی Nomad) توکن ایجاد می کند، می تواند ابزار دسترسی مرتبط با یک شناسه شغلی خاص را ذخیره کند. هنگامی که کار کامل شد، می‌توان از Accessor برای لغو فوری توکن داده شده به کار و تمام اعتبارنامه‌های اجاره‌ای آن استفاده کرد و احتمال اینکه یک بازیگر بد آنها را کشف و استفاده کند را محدود می‌کند.
دستگاه‌های حسابرسی می‌توانند به‌طور اختیاری تنظیم شوند تا دسترسی‌های رمز را در گزارش‌های حسابرسی مبهم نکنند. این روشی را برای لغو سریع توکن ها در مواقع اضطراری فراهم می کند. با این حال، همچنین به این معنی است که گزارش های حسابرسی می توانند برای انجام یک حمله انکار سرویس در مقیاس بزرگتر استفاده شوند.
در نهایت، تنها راه برای "فهرست کردن نشانه ها" از طریق دستور auth/token/accessors است که در واقع لیستی از دسترسی های نشانه را ارائه می دهد. در حالی که این هنوز یک نقطه پایانی خطرناک است (از آنجایی که فهرست کردن همه دسترسی‌ها به این معنی است که می‌توان از آنها برای باطل کردن همه نشانه‌ها استفاده کرد)، همچنین راهی برای بررسی و لغو مجموعه فعال فعلی توکن‌ها فراهم می‌کند.
Token Time-To-Live، توکن های دوره ای و حداکثر TTL های صریح
هر توکن غیر روت دارای یک زمان برای زندگی (TTL) است که یک دوره اعتبار فعلی از زمان ایجاد توکن یا آخرین زمان تمدید است، هر کدام که جدیدتر باشد.(توکن های ریشه ممکن است یک TTL مرتبط داشته باشند، اما TTL ممکن است 0 نیز باشد که نشان دهنده توکنی است که هرگز منقضی نمی شود). پس از بالا رفتن TTL فعلی، توکن دیگر کار نخواهد کرد -- آن و اجاره نامه های مرتبط با آن لغو می شوند.
اگر توکن قابل تمدید باشد، می‌توان از Vault درخواست کرد که دوره اعتبار توکن را با استفاده از تمدید نشانه طاق یا نقطه پایانی مناسب تمدید کند. در این زمان عوامل مختلفی وارد عمل می شوند. آنچه اتفاق می‌افتد بستگی به این دارد که آیا توکن یک توکن دوره‌ای است (برای ایجاد توسط کاربران root/sudo، نقش‌های ذخیره توکن، یا برخی روشهای احراز هویت در دسترس است)، حداکثر TTL صریح وصف شده باشد یا هیچکدام.
پرونده عمومی
در حالت کلی، جایی که هیچ نقطه یا مقدار صریحی حداکثر TTL روی توکن تنظیم نشده است، طول عمر توکن از زمان ایجاد آن با حداکثر TTL مقایسه خواهد شد. این حداکثر مقدار TTL به صورت پویا ایجاد می‌شود و می‌تواند از تمدید به تمدید تغییر کند، بنابراین وقتی اطلاعات یک نشانه جستجو می‌شود، مقدار آن نمایش داده نمی‌شود. مبتنی بر ترکیبی از عوامل است:
- سیستم حداکثر TTL ، که 32 روز است اما در پرونده پیکربندی Vault قابل تغییر است.
- حداکثر TTL با استفاده از تنظیم نصب روی یک کوه تنظیم شده است. این مقدار مجاز به غلبه بر سیستم حداکثر TTL است - می تواند طولانی تر یا کوتاه تر باشد و در صورت تنظیم این مقدار رعایت می شود.
- مقدار پیشنهادی با روش AUTH که این نشانه را صادر می کند. این ممکن است بر اساس هر رول ، هر گروه یا هر کاربر تنظیم شود. این مقدار مجاز به کمتر از Mount Max TTL است (یا در صورت تنظیم ، سیستم حداکثر TTL) ، اما مجاز به طولانی تر نیست.
توجه داشته باشید که مقادیر موجود در (2) و (3) ممکن است در هر زمان معین تغییر کند ، به همین دلیل تعیین نهایی در مورد جریان مجاز حداکثر TTL در زمان تجدید با استفاده از مقادیر فعلی انجام می شود. همچنین به همین دلیل مهم است که همیشه اطمینان حاصل شود که TTL از یک عمل تجدید در محدوده مجاز است. اگر این مقدار تمدید نشود ، احتمالاً TTL نشانه نمی تواند از ارزش فعلی خود گسترش یابد و مشتری ممکن است بخواهد مجدداً مجدداً تأیید کند و یک نشانه جدید را بدست آورد. با این حال ، خارج از تعامل مستقیم اپراتور ، Vault هرگز قبل از اتمام TTL برگشتی ، نشانه ای را لغو نمی کند.
حداکثر ttls صریح
توکن ها می توانند حداکثر TTL را بر روی آنها تنظیم کنند. این مقدار به یک حد سخت در طول عمر توکن تبدیل می شود-مهم نیست که مقادیر (1) ، (2) و (3) از مورد کلی ، این نشانه نمی تواند از این مقدار صریح و آشکار زندگی کند. این حتی در هنگام استفاده از نشانه های تناوبی برای فرار از مکانیسم طبیعی TTL تأثیر دارد.
در بعضی موارد ، داشتن نشانه ابطال مشکل ساز خواهد بود-به عنوان مثال ، اگر یک سرویس طولانی مدت نیاز به حفظ استخر اتصال SQL خود در مدت زمان طولانی داشته باشد. در این سناریو می توان از یک نشانه دوره ای استفاده کرد. نشانه های دوره ای از چند طریق قابل ایجاد است:
- با داشتن توانایی sudo یا نشانه ریشه با Auth/Token/ایجاد نقطه پایانی
- با استفاده از نقش های فروشگاه توکن
- با استفاده از یک روش AUTH که از صدور این موارد پشتیبانی می کند ، مانند Approle
در زمان شماره ، TTL یک نشانه دوره ای برابر با دوره پیکربندی شده خواهد بود. در هر زمان تجدید ، TTL دوباره به این دوره پیکربندی شده بازگردانده می شود و تا زمانی که نشانه در هر یک از این دوره های زمانی با موفقیت تجدید شود ، هرگز منقضی نمی شود. در خارج از نشانه های ریشه ، در حال حاضر تنها راه یک نشانه در طاق است که یک عمر نامحدود داشته باشد.
ایده پشت نشانه های دوره ای این است که انجام یک عمل نسبتاً مکرر برای سیستم ها و خدمات آسان است - به عنوان مثال ، هر دو ساعت یا حتی هر پنج دقیقه. بنابراین ، تا زمانی که یک سیستم به طور فعال این نشانه را تجدید کند - به عبارت دیگر ، تا زمانی که سیستم زنده باشد - سیستم مجاز به استفاده از نشانه و هرگونه اجاره نامه مرتبط است. با این حال ، اگر سیستم در این دوره از تجدید متوقف شود (به عنوان مثال ، اگر خاموش باشد) ، این نشانه نسبتاً سریع منقضی می شود. این خوب است که این دوره را تا حد امکان کوتاه نگه دارید و به طور کلی برای استفاده از توکن های دوره ای به انسان مفید نیست.
چند نکته مهم وجود دارد که باید هنگام استفاده از نشانه های تناوبی بدانید:
- هنگامی که یک نشانه دوره ای از طریق نقش فروشگاه توکن ایجاد می شود ، از مقدار فعلی تنظیم دوره نقش در زمان تجدید استفاده می شود
- یک نشانه با یک دوره و حداکثر TTL صریح مانند یک نشانه دوره ای عمل می کند اما با رسیدن به حداکثر TTL صریح ابطال می شود
برخی از نشانه ها قادر به محدود کردن CIDR (ها) هستند که دامنه IP های مشتری مجاز به استفاده از آنها را محدود می کنند. اینها بر همه نشانه ها تأثیر می گذارد به جز نشانه های ریشه ای غیر جذاب (کسانی که TTL صفر دارند). اگر یک نشانه ریشه انقضا داشته باشد ، تحت تأثیر اتصال CIDR قرار می گیرد.
انواع توکن با جزئیات
در حال حاضر دو نوع توکن وجود دارد.
نشانه های سرویس همان چیزی هستند که کاربران به طور کلی به عنوان نشانه های طاق "عادی" فکر می کنند. آنها از همه ویژگی ها ، مانند تجدید ، ابطال ، ایجاد نشانه های کودک و موارد دیگر پشتیبانی می کنند. آنها به همین ترتیب سنگین وزن برای ایجاد و ردیابی هستند.
نشانه های دسته ای از حباب های رمزگذاری شده استفاده می شوند که اطلاعات کافی را برای استفاده از آنها برای اقدامات طاق حمل می کنند ، اما برای ردیابی آنها نیازی به ذخیره سازی روی دیسک ندارند. در نتیجه آنها بسیار سبک و مقیاس پذیر هستند ، اما بیشترین انعطاف پذیری و ویژگی های نشانه های خدمات را ندارند.
مقایسه نوع توکن
این نمودار مرجع تفاوت رفتار بین خدمات و نشانه های دسته ای را توصیف می کند.
| نشانه های سرویس | نشانه های دسته ای | |
|---|---|---|
| می تواند نشانه های ریشه باشد | آره | No |
| می تواند نشانه های کودک ایجاد کند | آره | No |
| می تواند تجدید پذیر باشد | آره | No |
| قابل بازگشت دستی | آره | No |
| می تواند دوره ای باشد | آره | No |
| می تواند حداکثر TTL صریح داشته باشد | آره | خیر (همیشه از TTL ثابت استفاده می کند) |
| دارای دسترسی است | آره | No |
| Cubbyhole دارد | آره | No |
| با پدر و مادر ابطال شد (اگر یتیم نباشد) | آره | کار را متوقف می کند |
| تکالیف اسرار پویا | خود | والدین (اگر نه یتیم) |
| در خوشه های تکثیر عملکرد قابل استفاده است | No | بله (اگر یتیم) |
| مقیاس ایجاد با تعداد گره آماده به کار عملکرد | No | آره |
| هزینه | سنگین وزن ؛ذخیره سازی چندگانه در هر ایجاد توکن می نویسد | سبک وزن؛بدون هزینه ذخیره سازی برای ایجاد نشانه |
سرویس در مقابل دسته اجاره نامه توکن
اجاره نامه های ایجاد شده توسط نشانه های سرویس (از جمله اجاره توکن های کودک) به همراه نشانه خدمات ردیابی می شوند و با انقضای نشانه ابطال می شوند.
اجاره نامه های ایجاد شده توسط نشانه های دسته ای محدود به TTL باقی مانده از نشانه های دسته ای است و اگر نشانه دسته ای یتیم نباشد ، توسط والدین ردیابی می شود. آنها هنگامی که TTL Token Token منقضی می شود ، یا هنگامی که پدر و مادر Token Token ابطال می شوند ، ابطال می شوند (در این مرحله توکن دسته ای نیز دسترسی به طاق را رد می کند).
به عنوان یک نتیجه گیری ، می توان از نشانه های دسته ای در خوشه های تکثیر عملکرد استفاده کرد ، اما تنها در صورت یتیم بودن ، از آنجا که نشانه های غیر OPMAN قادر به اطمینان از اعتبار نشانه والدین نخواهند بود.< Pan> سبک وزن ؛بدون هزینه ذخیره سازی برای ایجاد نشانه
