این راهنما در مهر ۱۴۰۵ (اکتبر ۲۰۲۶) نوشته شده است. نسخه‌ها، تاریخ‌ها و رفتارهای پیش‌فرض با یادداشت‌های انتشار رسمی Vault در GitHub، مستندات developer.hashicorp.com و خبرهای رسمی IBM و OpenBao تطبیق داده شده و همه‌ی دستورهای بخش عملی روی ایمیج hashicorp/vault:2.2.0 اجرا و آزموده شده‌اند.
رمز پایگاه داده در فایل application.yml، کلید API در متغیر محیطی یک کانتینر، گواهی TLS روی دیسک یک سرور و توکن دسترسی در تاریخچه‌ی Git؛ تقریباً هر تیم نرم‌افزاری دیر یا زود با این صحنه‌ها روبه‌رو می‌شود. هرچه تعداد سرویس‌ها، محیط‌ها و افراد بیشتر شود، این «رازها» پراکنده‌تر، کهنه‌تر و خطرناک‌تر می‌شوند. بسیاری از نشت‌های اطلاعاتی بزرگ سال‌های اخیر نه با یک حمله‌ی پیچیده، که با یک رمز جاافتاده در یک مخزن کد یا یک کلید دسترسی بدون تاریخ انقضا شروع شده‌اند.
HashiCorp Vault شناخته‌شده‌ترین ابزار متن‌باز (و حالا Source-available) برای حل همین مسئله است: یک «گاوصندوق» متمرکز که رازها را رمزنگاری‌شده نگه می‌دارد، فقط به هویت‌های احرازشده و طبق Policy اجازه‌ی دسترسی می‌دهد، رازهای پویا و کوتاه‌عمر می‌سازد و از هر دسترسی، لاگ ممیزی ثبت می‌کند. در این مقاله از مفاهیم پایه شروع می‌کنیم، تاریخچه و تغییرات مجوز و مالکیت را مرور می‌کنیم، معماری و اجزای اصلی را توضیح می‌دهیم و در پایان Vault را با Docker و Docker Compose راه‌اندازی، با CLI کار و به یک برنامه‌ی Spring Boot متصل می‌کنیم.
در زبان امنیت، راز (Secret) هر داده‌ای است که داشتن آن به معنی داشتن دسترسی است: رمز عبور پایگاه داده، کلید API یک سرویس پرداخت، کلید خصوصی TLS، توکن یک حساب ابری، کلید SSH یا کلید رمزنگاری داده‌ها. مدیریت رازها (Secrets Management) مجموعه‌ی ابزارها و روش‌هایی است که چرخه‌ی عمر این داده‌ها را کنترل می‌کند: ساختن، ذخیره‌ی امن، توزیع به برنامه‌ها، چرخش دوره‌ای (Rotation)، ابطال و ممیزی.
در بیشتر سازمان‌ها رازها به‌مرور در جاهای مختلف پخش می‌شوند؛ پدیده‌ای که به آن Secret Sprawl می‌گویند. پیامدهای آن آشناست:
شرکت HashiCorp در سال ۲۰۱۲ توسط میچل هاشیموتو (Mitchell Hashimoto) و آرمون دادگر (Armon Dadgar) تأسیس شد و با ابزارهایی مثل Vagrant، Packer، Consul، Terraform و Nomad به یکی از نام‌های اصلی دنیای زیرساخت به‌عنوان کد تبدیل شد. Vault در آوریل ۲۰۱۵ با نسخه‌ی ۰٫۱ معرفی شد و نسخه‌ی ۱٫۰ آن در دسامبر ۲۰۱۸ منتشر شد. HashiCorp در دسامبر ۲۰۲۱ با نماد HCP در بورس نزدک عرضه‌ی عمومی شد.
در ۲۴ آوریل ۲۰۲۴، IBM توافق خرید HashiCorp را به ارزش تقریبی ۶٫۴ میلیارد دلار (۳۵ دلار برای هر سهم، به‌صورت نقدی) اعلام کرد. پس از طی مراحل نظارتی، این خرید در ۲۷ فوریه‌ی ۲۰۲۵ رسماً تکمیل شد و HashiCorp اکنون بخشی از IBM است. محصولات همچنان با نام HashiCorp عرضه می‌شوند و در سرآیند فایل‌های منبع Vault هم عبارت «Copyright IBM Corp.» دیده می‌شود.
تا تابستان ۲۰۲۳ کد Vault با مجوز متن‌باز Mozilla Public License 2.0 (MPL) منتشر می‌شد. در ۱۰ اوت ۲۰۲۳ HashiCorp اعلام کرد که همه‌ی نسخه‌های بعدی محصولاتش، از جمله Vault و Terraform، با Business Source License 1.1 (BSL یا BUSL) منتشر می‌شوند. BSL یک مجوز «منبع‌دسترس» (Source-available) است، نه متن‌باز به تعریف OSI: کد همچنان در GitHub منتشر می‌شود و استفاده‌ی داخلی، حتی تجاری و در Production، آزاد است؛ اما ارائه‌ی Vault به‌عنوان محصول یا سرویس پولی رقیب HashiCorp ممنوع است. هر نسخه چهار سال پس از انتشار به MPL 2.0 برمی‌گردد. APIها و SDKها، مثل کلاینت Go، با MPL باقی ماندند.
برای بیشتر تیم‌هایی که Vault را برای نیاز داخلی خودشان اجرا می‌کنند، این تغییر عملاً محدودیتی ایجاد نمی‌کند؛ اما شرکت‌هایی که Vault را درون محصول یا سرویس مدیریت‌شده‌ی خود عرضه می‌کردند، باید مسیر دیگری پیدا می‌کردند.
واکنش جامعه به تغییر مجوز، شکل‌گیری OpenBao بود: انشعابی (Fork) از آخرین کد Vault با مجوز MPL که در اواخر ۲۰۲۳ زیر چتر Linux Foundation (ابتدا در LF Edge) کار خود را آغاز کرد. نخستین نسخه‌ی پایدار آن، OpenBao 2.0.0، در ژوئیه‌ی ۲۰۲۴ منتشر شد و پروژه در ژوئن ۲۰۲۵ به‌عنوان پروژه‌ی Sandbox به OpenSSF (بنیاد امنیت متن‌باز، باز هم زیرمجموعه‌ی Linux Foundation) منتقل شد. OpenBao همچنان با MPL 2.0 منتشر می‌شود و تا مهر ۱۴۰۵ آخرین نسخه‌ی آن v2.7.1 (منتشرشده در ۱ اکتبر ۲۰۲۶) است. CLI آن به‌جای vault با bao اجرا می‌شود و از نظر API تا حد زیادی با Vault سازگار است، هرچند دو پروژه به‌مرور ویژگی‌های متفاوتی پیدا کرده‌اند.
Vault سال‌ها روی شاخه‌ی ۱.x ماند (آخرین آن‌ها 1.21 در اکتبر ۲۰۲۵) و در ۱۴ آوریل ۲۰۲۶ نسخه‌ی 2.0.0 منتشر شد. طبق صفحه‌ی Releases در GitHub، آخرین نسخه‌ی پایدار در زمان نگارش، Vault v2.2.0 است که ۱۵ اکتبر ۲۰۲۶ منتشر شده و ایمیج hashicorp/vault:2.2.0 هم در Docker Hub موجود است. چند تغییر مهم شاخه‌ی 2.x که در عمل به آن برمی‌خورید:
max_token_header_size روی Listener اندازه‌ی سرآیند توکن را (به‌طور پیش‌فرض ۸ کیلوبایت) محدود می‌کند.sys/rekey و sys/generate-root به‌طور پیش‌فرض نیازمند احراز هویت شده‌اند و گزینه‌ی tls_reload_interval برای بارگذاری دوباره‌ی گواهی‌ها به Listener اضافه شده است.vault اجرا می‌شود و قابلیت HCP Link حذف شده است.Vault یک فایل اجرایی واحد به زبان Go است که هم نقش سرور و هم نقش CLI را دارد. همه‌ی ارتباط‌ها از طریق یک HTTP API انجام می‌شود؛ CLI، رابط وب (UI) و کتابخانه‌های کلاینت همگی همین API را صدا می‌زنند. اجزای اصلی را می‌توان این‌طور خلاصه کرد:
Clients: CLI / UI / SDKs / Vault Agent / apps
|
HTTPS API (:8200)
|
+------------------------------------------------------------+
| Vault core |
| Auth methods -> Token store -> Policy check (ACL) |
| Secrets engines (KV, Database, PKI, Transit, AWS, ...) |
| Expiration manager (leases) Audit devices |
+-----------------------------+------------------------------+
|
Cryptographic barrier (AES-256-GCM)
|
Storage backend (Integrated Storage / Raft, Consul, ...)نکته‌ی مهم این است که در Vault همه چیز «مسیر» است: secret/data/myapp یک راز در موتور KV است، auth/approle/login ورود با AppRole است و sys/policies/acl مدیریت Policyهاست. Policyها هم دقیقاً روی همین مسیرها نوشته می‌شوند.
Vault پس از هر بار راه‌اندازی در وضعیت Sealed (مهروموم‌شده) است: داده‌ها روی Storage هستند، اما Vault کلید لازم برای رمزگشایی آن‌ها را ندارد و به هیچ درخواستی جز وضعیت و Unseal پاسخ نمی‌دهد. داده‌ها با یک کلید رمزنگاری (Encryption Key) رمز می‌شوند که خودش با یک Root Key (در نسخه‌های قدیمی Master Key) رمز شده است. فرایند Unseal یعنی بازسازی همین Root Key در حافظه.
در حالت پیش‌فرض، Vault هنگام مقداردهی اولیه (vault operator init) Root Key را با الگوریتم Shamir's Secret Sharing به چند تکه (Key Share) تقسیم می‌کند؛ مثلاً ۵ تکه که هر ۳ تای آن‌ها برای بازسازی کافی است. این تکه‌ها بین چند نفر مورد اعتماد پخش می‌شوند، بنابراین هیچ فرد واحدی به‌تنهایی نمی‌تواند Vault را باز کند. عیب این روش آشکار است: بعد از هر ری‌استارت یا خرابی، چند نفر باید دستی کلید وارد کنند.
در Auto-unseal وظیفه‌ی حفاظت از Root Key به یک سرویس مدیریت کلید قابل اعتماد سپرده می‌شود: AWS KMS، Azure Key Vault، Google Cloud KMS، OCI KMS، یک خوشه‌ی Vault دیگر (Transit Seal) یا در نسخه‌ی Enterprise یک HSM از طریق PKCS#11. Vault هنگام شروع، Root Key رمزشده را از Storage می‌خواند و برای رمزگشایی به KMS می‌فرستد. در این حالت به‌جای Unseal Key، هنگام init چند Recovery Key صادر می‌شود که برای کارهای حساسی مثل تولید Root Token جدید لازم است.
# Auto-unseal with AWS KMS (credentials come from the instance role / IRSA)
seal "awskms" {
region = "eu-central-1"
kms_key_id = "alias/vault-unseal"
}دسترسی به کلید KMS عملاً کلید کل Vault است؛ آن را با IAM سخت‌گیرانه، لاگ CloudTrail و جداسازی حساب‌ها محافظت کنید.
Vault داده‌های رمزشده را در یک Storage Backend نگه می‌دارد. گزینه‌های متعددی وجود دارد (فایل، حافظه، Consul، PostgreSQL، DynamoDB و …)، اما توصیه‌ی رسمی HashiCorp برای تقریباً همه‌ی استقرارهای جدید Integrated Storage مبتنی بر الگوریتم اجماع Raft است:
vault operator raft snapshot برای پشتیبان‌گیری و بازگردانی دارد و با retry_join نودها خودکار به خوشه می‌پیوندند.Raft برای تصمیم‌گیری به اکثریت (Quorum) نیاز دارد؛ به همین دلیل خوشه‌ها را با تعداد فرد نود می‌سازند. خوشه‌ی ۳ نودی خرابی یک نود و خوشه‌ی ۵ نودی خرابی دو نود را تحمل می‌کند. حالت file فقط برای تک‌نود آزمایشی و inmem فقط برای حالت Dev مناسب است.
| تعداد نود | Quorum | تحمل خرابی | کاربرد |
|---|---|---|---|
| ۱ | ۱ | ۰ | آزمایش و توسعه |
| ۳ | ۲ | ۱ نود | حداقل Production |
| ۵ | ۳ | ۲ نود | Production توصیه‌شده (مثلاً در سه Availability Zone) |
توکن روش اصلی احراز هویت در Vault است؛ همه‌ی Auth Methodها در نهایت یک توکن صادر می‌کنند و کلاینت آن را در سرآیند X-Vault-Token می‌فرستد. هر توکن مجموعه‌ای از Policyها، یک TTL (زمان اعتبار)، یک Max TTL و یک Accessor (شناسه‌ای برای مدیریت توکن بدون دانستن خود آن) دارد. توکن‌ها سلسله‌مراتبی‌اند: با ابطال یک توکن والد، همه‌ی توکن‌های فرزندش هم باطل می‌شوند. انواع مهم:
Policyها به زبان HCL (یا JSON) نوشته می‌شوند و برای هر مسیر مجموعه‌ای از Capabilityها تعیین می‌کنند: create، read، update، patch، delete، list، sudo و deny. مسیرها می‌توانند با * (پیشوند) و + (یک بخش از مسیر) عام شوند و deny همیشه بر بقیه اولویت دارد. دو Policy داخلی وجود دارد: root و default.
# myapp-read.hcl: read-only access to the application's KV v2 secrets
path "secret/data/myapp/*" {
capabilities = ["read"]
}
# Allow listing keys (KV v2 keeps metadata under a separate prefix)
path "secret/metadata/myapp/*" {
capabilities = ["list"]
}
# Explicitly forbid the production database credentials
path "secret/data/myapp/prod/db" {
capabilities = ["deny"]
}در موتور KV نسخه‌ی ۲، داده‌ها زیر secret/data/ و متادیتا زیر secret/metadata/ قرار می‌گیرند؛ فراموش کردن این نکته رایج‌ترین دلیل خطای permission denied است، چون CLI مسیر را بدون data/ نشان می‌دهد.
Auth Methodها روی مسیر auth/ فعال می‌شوند و هویت را از منابع مختلف می‌پذیرند. انتخاب درست آن، کلید حل مسئله‌ی «راز اول» (Secret Zero) است: برنامه برای گرفتن راز از Vault نباید خودش به یک راز دائمی دیگر وابسته باشد.
| روش | مناسب برای | نکته |
|---|---|---|
| Token | مدیر سیستم، اسکریپت‌های موقت | همیشه فعال است؛ پایه‌ی بقیه‌ی روش‌ها |
| Userpass | کاربران انسانی در محیط‌های کوچک | ساده، اما برای سازمان‌ها OIDC/LDAP بهتر است |
| AppRole | سرویس‌ها، ماشین‌ها و CI/CD | ترکیب Role ID (شبیه نام کاربری) و Secret ID (کوتاه‌عمر و محدود) |
| Kubernetes | Podها در Kubernetes | با توکن Service Account و TokenReview API؛ بدون راز اضافی |
| OIDC / JWT | ورود SSO انسان‌ها و توکن‌های CI مثل GitHub Actions و GitLab | اتصال به Keycloak، Entra ID، Okta و Google |
| AWS / Azure / GCP | ماشین‌ها و توابع ابری | هویت ابری (IAM Role، Managed Identity) را مستقیم می‌پذیرد |
| LDAP / Cert | Active Directory و کلاینت‌های دارای گواهی | TLS متقابل (mTLS) برای ماشین‌ها |
برای سرویس‌های غیرابری، AppRole متداول‌ترین انتخاب است. Role ID را می‌توان در ایمیج یا پیکربندی گذاشت، اما Secret ID باید از یک کانال مطمئن (مثلاً خط لوله‌ی استقرار) و ترجیحاً به‌صورت Response Wrapping تحویل شود؛ یعنی یک توکن یک‌بارمصرف که فقط یک بار و در مدت کوتاهی باز می‌شود. در Kubernetes و ابرها از روش‌های بومی همان پلتفرم استفاده کنید تا اصلاً Secret ID لازم نباشد.
هر Secrets Engine روی یک مسیر مستقل سوار می‌شود و می‌توان از یک نوع چند نمونه با پیکربندی متفاوت داشت (مثلاً kv-team-a/ و kv-team-b/). مهم‌ترین‌ها:
ذخیره‌ی کلید-مقدار با نسخه‌بندی: هر بار نوشتن، نسخه‌ی جدیدی می‌سازد و نسخه‌های قبلی (به‌طور پیش‌فرض ۱۰ نسخه) قابل بازیابی‌اند. حذف نرم (delete)، بازگردانی (undelete)، حذف دائمی (destroy) و نوشتن شرطی با cas (Check-and-Set) برای جلوگیری از رونویسی همزمان پشتیبانی می‌شود.
شاید قدرتمندترین قابلیت Vault: به‌جای یک رمز مشترک و دائمی، Vault برای هر درخواست یک کاربر جدید پایگاه داده با رمز تصادفی و TTL مشخص می‌سازد و پس از پایان Lease آن را حذف می‌کند. PostgreSQL، MySQL/MariaDB، MSSQL، Oracle، MongoDB، Redis، Elasticsearch و Snowflake از جمله پایگاه‌های پشتیبانی‌شده‌اند. حالت Static Role هم برای حساب‌های موجود، رمز را به‌صورت دوره‌ای خودکار عوض می‌کند. چون هر نمونه‌ی برنامه نام کاربری اختصاصی دارد، در لاگ پایگاه داده هم معلوم است کدام سرویس چه کرده است.
Vault می‌تواند CA ریشه یا میانی سازمان باشد و برای سرویس‌ها گواهی‌های X.509 کوتاه‌عمر (مثلاً ۲۴ ساعته) در چند میلی‌ثانیه صادر کند؛ مناسب mTLS بین میکروسرویس‌ها. پشتیبانی از ACME، CRL و OCSP، چند Issuer و در نسخه‌های جدید الگوریتم‌های پساکوانتومی مثل ML-DSA اضافه شده است.
Transit داده‌ی شما را ذخیره نمی‌کند؛ فقط آن را رمز، رمزگشایی، امضا یا HMAC می‌کند. برنامه متن را می‌فرستد و Ciphertextی مثل vault:v1:... تحویل می‌گیرد و خودش در پایگاه داده نگه می‌دارد. کلیدها هرگز Vault را ترک نمی‌کنند، چرخش کلید با یک دستور انجام می‌شود و rewrap داده‌های قدیمی را بدون افشای متن ساده به نسخه‌ی جدید کلید منتقل می‌کند.
موتور AWS برای هر درخواست یک کاربر IAM موقت، یا بهتر از آن اعتبارنامه‌ی STS مبتنی بر Assume Role با سیاست دسترسی مشخص می‌سازد. موتورهای مشابهی برای Azure، Google Cloud، SSH (امضای کلید با CA)، LDAP/Active Directory، RabbitMQ، Consul، Nomad و Kubernetes (ساخت توکن Service Account) وجود دارد.
هر راز پویا و هر توکن یک Lease دارد: شناسه‌ای یکتا، مدت اعتبار (lease_duration) و قابلیت تمدید. وقتی Lease تمام شود، Vault خودش راز را باطل می‌کند؛ مثلاً کاربر پایگاه داده را حذف می‌کند. این یعنی رازی که نشت کرده، چند ساعت بعد خودبه‌خود بی‌ارزش می‌شود.
-prefix می‌توان همه‌ی Leaseهای یک مسیر را یکجا باطل کرد. این ابزار اصلی واکنش به حادثه است.# Inspect, renew and revoke a dynamic database credential
vault lease lookup database/creds/app-rw/7bdS0hSt0mZ2j8HWJfYCxRcR
vault lease renew -increment=2h database/creds/app-rw/7bdS0hSt0mZ2j8HWJfYCxRcR
# Revoke one lease, or every credential ever issued by the role
vault lease revoke database/creds/app-rw/7bdS0hSt0mZ2j8HWJfYCxRcR
vault lease revoke -prefix database/creds/app-rwکلاینت‌های رسمی، Vault Agent و Spring Cloud Vault تمدید Lease را خودکار انجام می‌دهند؛ اگر خودتان کلاینت می‌نویسید، تمدید را در حدود دوسوم TTL انجام دهید و برای حالت شکست، دریافت اعتبارنامه‌ی جدید را پیش‌بینی کنید.
Audit Deviceها هر درخواست و پاسخ را با جزئیات کامل (هویت، مسیر، عملیات، IP و زمان) ثبت می‌کنند. مقادیر حساس مثل توکن‌ها و خود رازها با HMAC-SHA256 درهم‌سازی می‌شوند تا لاگ قابل جست‌وجو باشد ولی راز را لو ندهد. سه نوع وجود دارد: file، syslog و socket. یک نکته‌ی حیاتی: اگر Vault نتواند در هیچ‌کدام از Audit Deviceهای فعال بنویسد، برای حفظ امنیت به درخواست‌ها پاسخ نمی‌دهد. پس دست‌کم دو Audit Device داشته باشید و پر شدن دیسک لاگ را پایش کنید.
# Enable a file audit device and ship the file to your SIEM
vault audit enable file file_path=/vault/logs/audit.log
vault audit list -detailedNamespaceها (قابلیت Vault Enterprise و HCP Vault Dedicated) یک خوشه را به چند «Vault مجازی» مستقل تقسیم می‌کنند؛ هر Namespace، Policyها، Auth Methodها، Secrets Engineها و توکن‌های خودش را دارد و می‌توان مدیریت آن را به یک تیم یا مستأجر سپرد. در Community Edition همین جداسازی را با Mountهای جداگانه و نام‌گذاری مسیرها (مثلاً kv/team-a/) و Policyهای دقیق شبیه‌سازی می‌کنند.
سریع‌ترین راه آشنایی، حالت Dev است: Vault در حافظه اجرا می‌شود، خودکار init و unseal شده، موتور KV نسخه‌ی ۲ روی secret/ فعال است و Root Token از پیش مشخص است. هرگز از این حالت در Production استفاده نکنید؛ TLS ندارد و با توقف کانتینر همه‌ی داده‌ها از بین می‌رود.
# Dev mode: in-memory, auto-unsealed, HTTP only. For learning ONLY.
docker run -d --name vault-dev \
-p 127.0.0.1:8200:8200 \
-e VAULT_DEV_ROOT_TOKEN_ID=dev-only-token \
-e VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200 \
hashicorp/vault:2.2.0
# Point the CLI at it (inside the container or with a local vault binary)
export VAULT_ADDR=http://127.0.0.1:8200
export VAULT_TOKEN=dev-only-token
vault statusخروجی vault status باید Sealed false و Storage Type inmem را نشان دهد. رابط وب هم روی http://127.0.0.1:8200/ui با همان توکن در دسترس است. اگر CLI را روی سیستم خود نصب نکرده‌اید، دستورها را با docker exec -it vault-dev vault ... اجرا کنید.
در این بخش یک نود Vault با Integrated Storage (Raft)، TLS، Volumeهای ماندگار و UI روی پورت 8200 می‌سازیم. این چیدمان برای آزمایشگاه، محیط Staging یا یک سرویس داخلی کوچک مناسب است و در Production واقعی باید به خوشه‌ی ۳ یا ۵ نودی و Auto-unseal گسترش یابد (بخش ۱۵).
vault-lab/
├── docker-compose.yml
├── config/
│ └── vault.hcl
└── certs/
├── ca.crt
├── vault.crt
└── vault.keyدر Production گواهی را از CA سازمان یا موتور PKI یک Vault دیگر بگیرید. برای آزمایشگاه یک CA خودامضا کافی است:
cd certs
# Lab CA
openssl req -x509 -newkey rsa:2048 -nodes -days 3650 \
-subj "/CN=Lab Vault CA" -keyout ca.key -out ca.crt
# Server key + CSR + certificate with the names clients will use
openssl req -newkey rsa:2048 -nodes -subj "/CN=vault.example.internal" \
-keyout vault.key -out vault.csr
printf "subjectAltName=DNS:vault.example.internal,DNS:vault-1,DNS:localhost,IP:127.0.0.1\n" > san.ext
openssl x509 -req -in vault.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
-days 825 -extfile san.ext -out vault.crt
# The container runs as user "vault" (uid 100, gid 1000): let it read the key
sudo chown 100:1000 vault.key vault.crt ca.crt && sudo chmod 600 vault.key# Single-node Raft (integrated storage) - production-like lab
ui = true
disable_mlock = true # recommended with integrated storage; disable swap on the host instead
storage "raft" {
path = "/vault/file"
node_id = "vault-1"
}
listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "0.0.0.0:8201"
tls_cert_file = "/vault/certs/vault.crt"
tls_key_file = "/vault/certs/vault.key"
tls_min_version = "tls12"
}
api_addr = "https://vault.example.internal:8200"
cluster_addr = "https://vault-1:8201"
# Expose Prometheus metrics at /v1/sys/metrics
telemetry {
prometheus_retention_time = "30s"
disable_hostname = true
}درباره‌ی mlock و IPC_LOCK: Vault به‌طور سنتی با فراخوانی mlock جلوی رفتن حافظه‌اش به Swap را می‌گیرد و برای این کار در کانتینر به قابلیت IPC_LOCK نیاز دارد. HashiCorp برای Integrated Storage توصیه می‌کند disable_mlock = true باشد (چون mlock با فایل‌های نگاشت‌شده در حافظه‌ی Raft سازگار نیست) و به‌جای آن Swap روی میزبان خاموش شود. یادداشت‌های انتشار 2.2 درباره‌ی ایمیج کانتینر هم همین مسیر را پیشنهاد می‌کنند. افزودن cap_add: IPC_LOCK بی‌ضرر است و اگر روی ایمیج یا پیکربندی‌ای mlock را فعال نگه دارید، لازم می‌شود.
services:
vault:
image: hashicorp/vault:2.2.0
container_name: vault-1
hostname: vault-1
command: ["vault", "server", "-config=/vault/config/vault.hcl"]
ports:
- "8200:8200" # API + UI
cap_add:
- IPC_LOCK # harmless; only needed if you keep mlock enabled
environment:
VAULT_ADDR: "https://127.0.0.1:8200"
VAULT_CACERT: "/vault/certs/ca.crt"
volumes:
- ./config:/vault/config:ro
- ./certs:/vault/certs:ro
- vault-data:/vault/file # Raft data (encrypted by the barrier)
- vault-logs:/vault/logs # audit log
restart: unless-stopped
healthcheck:
test: ["CMD", "vault", "status"]
interval: 15s
timeout: 5s
retries: 5
volumes:
vault-data:
vault-logs:دقت کنید که command مستقیماً vault server -config=... را اجرا می‌کند تا فقط همین فایل پیکربندی بارگذاری شود و پرچم‌های پیش‌فرض اسکریپت ورودی ایمیج (که برای حالت Dev در نظر گرفته شده‌اند) دخالتی نداشته باشند. Healthcheck هم تا زمانی که Vault باز نشده ناسالم گزارش می‌شود، چون vault status برای Vault مهروموم‌شده کد خروج ۲ برمی‌گرداند.
docker compose up -d
docker exec vault-1 vault status # Initialized false, Sealed true
# Initialize: 5 key shares, any 3 can unseal. Store the output OFFLINE and split it!
docker exec vault-1 vault operator init -key-shares=5 -key-threshold=3
# Run three times, each time with a different unseal key (prompted, not echoed)
docker exec -it vault-1 vault operator unseal
docker exec -it vault-1 vault operator unseal
docker exec -it vault-1 vault operator unseal
docker exec vault-1 vault status # Sealed false, Storage Type raft, HA Mode activeخروجی init شامل ۵ Unseal Key و یک Initial Root Token است. این خروجی را هرگز در ترمینال مشترک، چت یا فایل رمزنشده نگه ندارید؛ تکه‌ها را بین افراد مختلف پخش کنید یا با پرچم -pgp-keys هر تکه را با کلید PGP صاحبش رمز کنید. پس از باز شدن، UI روی https://vault.example.internal:8200/ui در دسترس است (CA آزمایشگاه را به مرورگر یا سیستم معرفی کنید).
# Log in with the initial root token only to bootstrap, then enable the basics
docker exec -it vault-1 vault login
docker exec vault-1 vault secrets enable -path=secret kv-v2
docker exec vault-1 vault audit enable file file_path=/vault/logs/audit.log
docker exec vault-1 vault operator raft list-peers
# Take a first snapshot (copy it off the host afterwards)
docker exec vault-1 vault operator raft snapshot save /vault/file/first.snap# Write two keys at secret/myapp/config (KV v2 creates version 1)
vault kv put -mount=secret myapp/config db.username=app db.password='S3cr3t!'
# Read the whole secret, a single field, or JSON for scripts
vault kv get -mount=secret myapp/config
vault kv get -mount=secret -field=db.password myapp/config
vault kv get -mount=secret -format=json myapp/config
# Versioning: update, read an older version, roll back
vault kv patch -mount=secret myapp/config db.password='N3wS3cr3t!'
vault kv get -mount=secret -version=1 myapp/config
vault kv rollback -mount=secret -version=1 myapp/config
vault kv metadata get -mount=secret myapp/config# Upload the read-only policy shown in section 6
vault policy write myapp-read myapp-read.hcl
vault policy list
vault policy read myapp-read
# Quick test: a short-lived token that only has this policy
vault token create -policy=myapp-read -ttl=15mvault auth enable approle
# Role for the "myapp" service: short tokens, limited Secret IDs
vault write auth/approle/role/myapp \
token_policies="myapp-read" \
token_ttl=1h token_max_ttl=4h \
secret_id_ttl=24h secret_id_num_uses=10
# Role ID is not secret; Secret ID is (deliver it via your CD pipeline)
vault read -field=role_id auth/approle/role/myapp/role-id
vault write -f -field=secret_id auth/approle/role/myapp/secret-id
# Better: hand over a wrapped Secret ID that can be unwrapped once within 120s
vault write -wrap-ttl=120s -f auth/approle/role/myapp/secret-id
# The application logs in and receives its own token
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
# With that token it can read, but not write
VAULT_TOKEN="$APP_TOKEN" vault kv get -mount=secret myapp/config # OK
VAULT_TOKEN="$APP_TOKEN" vault kv put -mount=secret myapp/config x=1 # permission denied# Dynamic PostgreSQL users
vault secrets enable database
vault write database/config/appdb \
plugin_name=postgresql-database-plugin \
allowed_roles="app-rw" \
connection_url="postgresql://{{username}}:{{password}}@db.example.internal:5432/appdb" \
username="vault_admin" password="initial-password"
# Rotate the bootstrap password so only Vault knows it
vault write -f database/rotate-root/appdb
vault write database/roles/app-rw db_name=appdb default_ttl=1h max_ttl=24h \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
vault read database/creds/app-rw # new username/password + lease_id every time
# Encryption as a service
vault secrets enable transit
vault write -f transit/keys/orders
vault write transit/encrypt/orders plaintext=$(echo -n "4111-1111-1111-1111" | base64)
vault write -field=plaintext transit/decrypt/orders ciphertext="vault:v1:..." | base64 -d
vault write -f transit/keys/orders/rotate # new key version; old ciphertext still decryptsسه الگوی اصلی برای رساندن راز به برنامه وجود دارد:
Spring Cloud Vault رازهای Vault را مستقیماً به PropertySourceهای Spring اضافه می‌کند؛ یعنی کلیدهای KV مثل هر Property دیگری با @Value یا @ConfigurationProperties در دسترس‌اند و حتی می‌توان مستقیماً spring.datasource.password را در Vault گذاشت. نسخه‌ی 5.0.x این پروژه با Spring Boot 4 و نسخه‌ی 4.3.x با Spring Boot 3.5 هم‌خوان است؛ نسخه را از طریق BOM رسمی spring-cloud-dependencies تعیین کنید. کد کامل این مثال در مخزن vault-spring-boot-sample به‌عنوان نمونه‌ی همراه این مقاله معرفی شده است.
<!-- pom.xml: version comes from the spring-cloud-dependencies BOM -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-vault-config</artifactId>
</dependency>ابتدا رازهای سرویس را در مسیری هم‌نام با spring.application.name بنویسید و Policy مناسب را به AppRole آن بدهید:
vault kv put -mount=secret orders-service \
spring.datasource.username=orders \
spring.datasource.password='Str0ngP@ss' \
payment.api-key='pk_live_xxx'
# orders-service.hcl: what the service may read
# path "secret/data/orders-service" { capabilities = ["read"] }
# path "secret/data/application" { capabilities = ["read"] }# src/main/resources/application.yml
spring:
application:
name: orders-service # KV path: secret/orders-service (+ /{profile})
config:
import: "vault://" # load Vault as a config source at startup
cloud:
vault:
uri: https://vault.example.internal:8200
authentication: APPROLE
app-role:
role-id: ${VAULT_ROLE_ID} # injected by the platform, never committed
secret-id: ${VAULT_SECRET_ID}
app-role-path: approle
ssl:
trust-store: classpath:vault-truststore.p12 # trust the Vault CA
trust-store-password: ${TRUSTSTORE_PASSWORD}
kv:
enabled: true
backend: secret # KV v2 mount
default-context: application
fail-fast: true # refuse to start without secrets// PaymentClient.java: secrets are ordinary Spring properties
@Service
public class PaymentClient {
// Resolved from secret/orders-service in Vault at startup
@Value("${payment.api-key}")
private String apiKey;
public String authorizationHeader() {
// Never log the secret itself
return "Bearer " + apiKey;
}
}برای رازهای پویای پایگاه داده کافی است spring.cloud.vault.database.enabled=true و spring.cloud.vault.database.role=app-rw را تنظیم کنید؛ Spring Cloud Vault هنگام شروع یک کاربر موقت می‌گیرد، آن را در spring.datasource.username/password قرار می‌دهد و Lease را تا زمان اجرای برنامه تمدید می‌کند. در Kubernetes هم با authentication: KUBERNETES و یک Role مناسب، اصلاً به Role ID و Secret ID نیازی نیست.
tls_disable یا VAULT_SKIP_VERIFY در Production.retry_join برای پیوستن خودکار و یک Load Balancer که با /v1/sys/health نود فعال را تشخیص دهد.vault operator raft snapshot save به‌صورت زمان‌بندی‌شده، انتقال به مخزن جدا و رمزشده، و آزمودن بازگردانی در محیط جداگانه.vault token revoke روی Root Token و در صورت نیاز تولید موقت آن با vault operator generate-root و حضور دارندگان کلید.* گسترده، TTLهای کوتاه و ترجیح رازهای پویا به رازهای ایستا./v1/sys/metrics، هشدار برای Sealed شدن، تغییر Leader، تأخیر درخواست‌ها، رشد Leaseها و انقضای گواهی‌ها.Vault تنها گزینه نیست. جدول زیر تصویری کلی از ابزارهای رایج می‌دهد:
| ابزار | نوع و مجوز | رازهای پویا | محیط مناسب | نکته‌ی کلیدی |
|---|---|---|---|---|
| HashiCorp Vault | خودمیزبان (BSL) یا HCP Vault Dedicated | بله، گسترده | چندابری، هیبریدی و On-prem | کامل‌ترین قابلیت‌ها؛ نیازمند تخصص عملیاتی |
| OpenBao | خودمیزبان، MPL 2.0 | بله | مشابه Vault | انشعاب متن‌باز جامعه‌محور زیر OpenSSF |
| AWS Secrets Manager | سرویس مدیریت‌شده | چرخش خودکار با Lambda | AWS | یکپارچگی عمیق با IAM؛ هزینه به ازای هر راز |
| AWS KMS | سرویس مدیریت کلید | خیر (کلید، نه راز) | AWS | برای رمزنگاری و Auto-unseal؛ جایگزین مخزن راز نیست |
| Azure Key Vault | سرویس مدیریت‌شده | محدود | Azure | راز، کلید و گواهی در یک سرویس؛ HSM مدیریت‌شده |
| Google Secret Manager | سرویس مدیریت‌شده | خیر (چرخش با رویداد) | Google Cloud | ساده و ارزان؛ نسخه‌بندی و IAM |
| CyberArk Conjur | متن‌باز و تجاری | محدود | سازمان‌های بزرگ | تمرکز بر هویت ماشین‌ها و PAM |
| Doppler / Infisical | SaaS؛ Infisical متن‌باز و خودمیزبان هم دارد | Infisical: بله | تیم‌های توسعه و استارتاپ‌ها | تجربه‌ی کاربری عالی و همگام‌سازی با پلتفرم‌ها |
| Kubernetes Secrets | داخلی Kubernetes | خیر | فقط Kubernetes | پیش‌فرض فقط Base64؛ رمزنگاری etcd و RBAC را جدا فعال کنید |
| Sealed Secrets / SOPS | متن‌باز، GitOps | خیر | Git و Kubernetes | رازِ رمزشده در Git؛ بدون Lease، ممیزی و رازهای پویا |
قاعده‌ی سرانگشتی: اگر کاملاً در یک ابر هستید و فقط راز ایستا دارید، سرویس بومی همان ابر ساده‌تر و ارزان‌تر است. اگر چندابری یا On-prem هستید، رازهای پویا، PKI داخلی یا رمزنگاری به‌عنوان سرویس می‌خواهید، Vault یا OpenBao انتخاب طبیعی‌اند. Sealed Secrets و SOPS هم مکمل خوبی برای GitOps هستند، نه جایگزین یک مدیر راز کامل.
| نشانه | علت محتمل | راه‌حل |
|---|---|---|
Vault is sealed | ری‌استارت نود یا از دست رفتن دسترسی به KMS | vault operator unseal یا بررسی IAM/شبکه‌ی KMS |
permission denied روی KV | فراموش کردن data/ یا metadata/ در Policy | مسیر Policy را secret/data/... بنویسید؛ vault token capabilities را بزنید |
x509: certificate signed by unknown authority | CA به کلاینت معرفی نشده | تنظیم VAULT_CACERT یا Truststore؛ نه VAULT_SKIP_VERIFY |
connection refused یا server gave HTTP response to HTTPS client | ناهمخوانی http و https در VAULT_ADDR | پروتکل و پورت را با Listener تطبیق دهید |
permission denied روی /vault/file در Docker | مالکیت Volume یا Bind Mount با کاربر vault (uid 100) نمی‌خواند | از Named Volume استفاده کنید یا chown 100:1000 بزنید |
| خطای mlock در شروع کانتینر | نبود IPC_LOCK در حالی که mlock فعال است | disable_mlock = true و خاموش کردن Swap، یا افزودن cap_add: IPC_LOCK |
| همه‌ی درخواست‌ها بی‌پاسخ می‌مانند | Vault نمی‌تواند در Audit Device بنویسد (مثلاً دیسک پر) | آزاد کردن فضا، چرخش لاگ و داشتن دست‌کم دو Audit Device |
| خوشه Leader ندارد | از دست رفتن Quorum در Raft | بازگرداندن نودها؛ در بدترین حالت بازیابی از Snapshot یا peers.json |
lease not found یا قطع ناگهانی اتصال DB | پایان Max TTL یا ابطال Lease | TTLها را بازبینی و منطق دریافت مجدد اعتبارنامه را پیاده کنید |
| خطای پیکربندی پس از ارتقا به 2.x | مسیرهای غیرکانونی یا ویژگی تکراری در HCL | یادداشت‌های انتشار را بخوانید و پیکربندی را در Staging آزمایش کنید |
# Handy diagnostics
vault status # sealed? HA mode? version?
vault token lookup # who am I, which policies, TTL left
vault token capabilities secret/data/myapp/config
vault operator raft list-peers # cluster membership and leader
vault read sys/health # same data the load balancer sees
vault debug -duration=2m -output=/tmp/vault-debug.tar.gz # bundle for support| اصطلاح | توضیح |
|---|---|
| Secret | هر داده‌ای که داشتنش به معنی دسترسی است: رمز، کلید، توکن یا گواهی |
| Seal / Unseal | حالت قفل Vault پس از شروع / بازسازی Root Key در حافظه برای باز کردن آن |
| Shamir's Secret Sharing | تقسیم کلید به n تکه که هر k تکه برای بازسازی کافی است |
| Auto-unseal | سپردن حفاظت Root Key به KMS یا HSM برای باز شدن خودکار |
| Barrier | لایه‌ی رمزنگاری بین هسته‌ی Vault و Storage |
| Integrated Storage (Raft) | ذخیره‌سازی داخلی و تکثیرشده‌ی Vault بدون وابستگی خارجی |
| Token | شناسه‌ی دسترسی که پس از احراز هویت صادر می‌شود و Policyها به آن متصل‌اند |
| Policy | قواعد HCL که مشخص می‌کند روی هر مسیر چه Capabilityهایی مجاز است |
| Auth Method | روش احراز هویت؛ مانند AppRole، Kubernetes، OIDC و Userpass |
| Secrets Engine | افزونه‌ی ذخیره یا تولید راز روی یک مسیر؛ مانند KV، Database، PKI و Transit |
| Dynamic Secret | اعتبارنامه‌ای که هنگام درخواست ساخته و پس از پایان Lease باطل می‌شود |
| Lease | مدت اعتبار و شناسه‌ی قابل تمدید یا ابطال یک راز پویا یا توکن |
| Response Wrapping | تحویل یک پاسخ در قالب توکن یک‌بارمصرف و کوتاه‌عمر |
| Audit Device | مقصدی که همه‌ی درخواست‌ها و پاسخ‌ها با HMAC در آن ثبت می‌شوند |
| Namespace | تقسیم یک خوشه به چند Vault مجازی مستقل (Enterprise) |
| Vault Agent | فرایند کمکی برای احراز هویت، تمدید و رندر رازها برای برنامه |
مدیریت رازها دیگر یک «کار جانبی» نیست؛ بخش مهمی از امنیت هر سیستم مدرن است. HashiCorp Vault با سد رمزنگاری، Policyهای مبتنی بر مسیر، Auth Methodهای متنوع، رازهای پویا با Lease و ممیزی کامل، مسئله‌ی پراکندگی رازها را به‌صورت ریشه‌ای حل می‌کند. امروز Vault با نسخه‌ی 2.2.0 زیر چتر IBM فعال‌تر از همیشه توسعه می‌یابد و برای کسانی که مجوز متن‌باز برایشان حیاتی است، OpenBao جایگزینی جدی و سازگار است.
مسیر پیشنهادی برای شروع: Vault را در حالت Dev اجرا کنید و با KV، Policy و AppRole کار کنید؛ سپس چیدمان Docker Compose با Raft و TLS این مقاله را بالا بیاورید و یک سرویس واقعی، مثلاً یک برنامه‌ی Spring Boot، را به آن وصل کنید. وقتی آماده‌ی Production شدید، چک‌لیست بخش ۱۵ را مو به مو اجرا کنید: خوشه‌ی سه یا پنج نودی، Auto-unseal، Snapshot، Audit، ابطال Root Token و پایش. و فراموش نکنید که بهترین راز، رازی است که عمرش کوتاه است.
راهنمای جامع و کاربردی پراکسی سرور به زبان ساده: تفاوت پراکسی فوروارد، معکوس و شفاف، انواع HTTP و SOCKS، الگوریتم‌های توزیع بار و آموزش کامل Nginx شامل نصب، ساختار پیکربندی، Reverse Proxy، SSL با Let's Encrypt، WebSocket، کش، محدودیت نرخ، هدرهای امنیتی و عیب‌یابی خطاهای 502 و 504.
راهنمای کامل و کاربردی WSO2: آشنایی با شرکت و محصولاتش، معماری API Manager نسخه‌ی 4.7، نصب با Docker و Docker Compose، پیکربندی deployment.toml، راه‌اندازی SSL با Let's Encrypt و Nginx، نکات استقرار Production و مقایسه با رقبا.
آموزش شبکه کردن CALL OF DUTY 4:MODERN WARFARE 1 برای شبکه کردن این بازی شما نیاز به یک سری پچ ها و تنظیمات دارید که باید مرحله به مرحله انجام بشه مرحله اول مثل همیشه نصب یک نسخه…
نظرها هنوز نظری ثبت نشده
برای ثبت نظر، صفحه را در مرورگر باز کنید.