Forwarded from Academy and Foundation unixmens | Your skills, Your future
Forwarded from Academy and Foundation unixmens | Your skills, Your future
Forwarded from Academy and Foundation unixmens | Your skills, Your future
Forwarded from Academy and Foundation unixmens | Your skills, Your future
مفهوم و ساختار Ansible چیست ؟
چنانچه شما بعنوان یک Linux System Administratior در دیتا سنتری کار کنید میدانید که مدیریت و راهبری تعداد زیاد server کار آسانی نیست مثلا اگر قرار باشد تعداد ۵ تا server را بروز رسانی کنید شاید کار زیاد زمان بری نباشد اما اگر لازم باشد تعداد ۱۰۰ یا ۲۰۰ تا بیشتر را پشتیبانی و بروز رسانی کنید کاری بسیار پر استرس و زمان بر خواهد بود .
در سالهای گذشته بیشتر
System Administrator
ها از قابلیت نوشتن script به منظور راهبری و پشتیبانی server های خود استفاده میکردند که نیاز به دانش عمیق در برنامه نویسی با زبان script داشت و مستلزم وقت برای نوشتن script های صحیح و دقیق و کارا بود . فرض کنید میخواهید کلیه server های خود را update کنید و یا می خواهید backup بگیرید , چنانچه بخواهید بر روی هر server جداگانه این کار را انجام دهید مسلما کاری وقت گیر است که در این زمانه وقت و زمان بسیار در سیستم های آنلاین و برخط مهم است و اینکه server و service شما بالا و برخط باشد و در همان شرایط بتوانید عملیات لازم را روی آن انجام دهید مسئله ای ارزشمند است .
در واقع Ansible یک برنامه opensource برای متمرکز کردن کارهای دیتاسنترها روی server های می باشد . بوسیله Ansible قادر خواهید بود که بسیاری از وظایف ادمین را بصورت خودکار راه اندازی و تعریف کنید تا در زمان مناسب بصورت دremote یا از راه دور روی ماشین های شما اجرا گردد. ساختار Ansible بگونه ای طراحی شده است که شما را قادر خواهد ساخت بدون shutdown کردن سیستم به عملیات مختلف روی ماشین های خود ادامه دهید .
مثلا Ansible میتواند عملیاتی مثل update ماشین های مختلف را بصورت Zero Downtime انجام دهد . در ضمن system admin نیازی به نوشتن script های بهینه شده نداشته و میتواند از زبانهای high-level در ansible براحتی استفاده نماید . در Ansible می توانید وظایف را بصورت گروه های مختلف مثلا گروه های مرتبط با host یا نوع آنها و ساختار معماری آنها تعریف نمایید . مفهومی بنام paly در Ansible داریم که مجموع از وظایف مرتبط با یک گروه از host ها را برعهده دارد و فایلی که یک یا بیش از یکی از این palys ها را شامل باشد palybook نامیده می شود . معماری Ansible بصورت agentless است . هر زمانی که Ansible کاری را اجرا کند و فرمانی صادر
کند این کار به ماشین های راه دور منتقل می شود . از آنجاییکه Ansible تعداد زیادی بیش از صد ماژول در core خود دارد لذا کار system administrator ها را خیلی راحت می کند .
در واقع Ansible اولین بار توسط Michael DeHaam طراحی و تولید شد ، شخصی که بوجود آورنده برنامه Collber provisioning بود. از آنجاییکه Ansible بسیار ساده است لذا بسیاری از system admin ها از آن استفاده میکنند . همچنین Developer ها یا توسعه دهندگان برنامه ها نیز می توانند براحتی از Ansible استفاده نمایند زیرا بر پایه زبان Python نوشته شده است . Ansible توسط ابزارهای DevOps مثل Vagrant و Jenkins پشتیبانی می شود. در این بین کارهای زیادی هم وجود دارد که ansible قادر به انجام آنها نیست . مثلا Ansible نمیتواند تغیراتی که توسط کابران در سیستم انجام میگردد را audit یا رسد کند . مثلا اینکه این فایل را چه کسی تغییر داده است .
لیست زیر نمونه ای از کارهایی که توسط Ansible قابل انجام نمی باشد آمده است :
در واقع Ansible می تواند package های مورد نیاز در زمان نصب را اضافه کند، اما قادر به نصب اولیه در حالت minimal روی سیستم نیست . هر سیستمی را میتوان بصورت Minimal راه اندازی کرده و سپس توسط Kickstart یا ابزارهای مشابه یک image از آن تهیه نمود، سپس با Ansible برای پیکربندی های دیگر استفاده کرد .
با اینکه Ansible قادر است پیکربندی مربوط به فایروال را تنظیم نماید اما بر آن نظارتی ندارد . Ansible نمی تواند تغییرات روی فایل های داخل سسیتم را پیگیری کند که آیا این تغییرات توسط کاربر انجام شده یا توسط process . غالبا بهتر است که این گونه تغییرات بهتر است با ابزارهای دیگر مخصوص version control یا ابزارهای audit خود سیستم عامل لینوکس انجام پذیرد.
#ansible #sys_admin #devpos @unixmens
چنانچه شما بعنوان یک Linux System Administratior در دیتا سنتری کار کنید میدانید که مدیریت و راهبری تعداد زیاد server کار آسانی نیست مثلا اگر قرار باشد تعداد ۵ تا server را بروز رسانی کنید شاید کار زیاد زمان بری نباشد اما اگر لازم باشد تعداد ۱۰۰ یا ۲۰۰ تا بیشتر را پشتیبانی و بروز رسانی کنید کاری بسیار پر استرس و زمان بر خواهد بود .
در سالهای گذشته بیشتر
System Administrator
ها از قابلیت نوشتن script به منظور راهبری و پشتیبانی server های خود استفاده میکردند که نیاز به دانش عمیق در برنامه نویسی با زبان script داشت و مستلزم وقت برای نوشتن script های صحیح و دقیق و کارا بود . فرض کنید میخواهید کلیه server های خود را update کنید و یا می خواهید backup بگیرید , چنانچه بخواهید بر روی هر server جداگانه این کار را انجام دهید مسلما کاری وقت گیر است که در این زمانه وقت و زمان بسیار در سیستم های آنلاین و برخط مهم است و اینکه server و service شما بالا و برخط باشد و در همان شرایط بتوانید عملیات لازم را روی آن انجام دهید مسئله ای ارزشمند است .
در واقع Ansible یک برنامه opensource برای متمرکز کردن کارهای دیتاسنترها روی server های می باشد . بوسیله Ansible قادر خواهید بود که بسیاری از وظایف ادمین را بصورت خودکار راه اندازی و تعریف کنید تا در زمان مناسب بصورت دremote یا از راه دور روی ماشین های شما اجرا گردد. ساختار Ansible بگونه ای طراحی شده است که شما را قادر خواهد ساخت بدون shutdown کردن سیستم به عملیات مختلف روی ماشین های خود ادامه دهید .
مثلا Ansible میتواند عملیاتی مثل update ماشین های مختلف را بصورت Zero Downtime انجام دهد . در ضمن system admin نیازی به نوشتن script های بهینه شده نداشته و میتواند از زبانهای high-level در ansible براحتی استفاده نماید . در Ansible می توانید وظایف را بصورت گروه های مختلف مثلا گروه های مرتبط با host یا نوع آنها و ساختار معماری آنها تعریف نمایید . مفهومی بنام paly در Ansible داریم که مجموع از وظایف مرتبط با یک گروه از host ها را برعهده دارد و فایلی که یک یا بیش از یکی از این palys ها را شامل باشد palybook نامیده می شود . معماری Ansible بصورت agentless است . هر زمانی که Ansible کاری را اجرا کند و فرمانی صادر
کند این کار به ماشین های راه دور منتقل می شود . از آنجاییکه Ansible تعداد زیادی بیش از صد ماژول در core خود دارد لذا کار system administrator ها را خیلی راحت می کند .
در واقع Ansible اولین بار توسط Michael DeHaam طراحی و تولید شد ، شخصی که بوجود آورنده برنامه Collber provisioning بود. از آنجاییکه Ansible بسیار ساده است لذا بسیاری از system admin ها از آن استفاده میکنند . همچنین Developer ها یا توسعه دهندگان برنامه ها نیز می توانند براحتی از Ansible استفاده نمایند زیرا بر پایه زبان Python نوشته شده است . Ansible توسط ابزارهای DevOps مثل Vagrant و Jenkins پشتیبانی می شود. در این بین کارهای زیادی هم وجود دارد که ansible قادر به انجام آنها نیست . مثلا Ansible نمیتواند تغیراتی که توسط کابران در سیستم انجام میگردد را audit یا رسد کند . مثلا اینکه این فایل را چه کسی تغییر داده است .
لیست زیر نمونه ای از کارهایی که توسط Ansible قابل انجام نمی باشد آمده است :
در واقع Ansible می تواند package های مورد نیاز در زمان نصب را اضافه کند، اما قادر به نصب اولیه در حالت minimal روی سیستم نیست . هر سیستمی را میتوان بصورت Minimal راه اندازی کرده و سپس توسط Kickstart یا ابزارهای مشابه یک image از آن تهیه نمود، سپس با Ansible برای پیکربندی های دیگر استفاده کرد .
با اینکه Ansible قادر است پیکربندی مربوط به فایروال را تنظیم نماید اما بر آن نظارتی ندارد . Ansible نمی تواند تغییرات روی فایل های داخل سسیتم را پیگیری کند که آیا این تغییرات توسط کاربر انجام شده یا توسط process . غالبا بهتر است که این گونه تغییرات بهتر است با ابزارهای دیگر مخصوص version control یا ابزارهای audit خود سیستم عامل لینوکس انجام پذیرد.
#ansible #sys_admin #devpos @unixmens
مقاله ansible که نوشتم تقدیم دوستان
https://www.dropbox.com/s/7u5tnet451k3gk3/Ansible.pdf?dl=0
#ansible @unixmens
https://www.dropbox.com/s/7u5tnet451k3gk3/Ansible.pdf?dl=0
#ansible @unixmens
Dropbox
Ansible.pdf
Shared with Dropbox
Forwarded from Academy and Foundation unixmens | Your skills, Your future (yashar esmaildokht 🐧)
مقاله ansible که نوشتم تقدیم دوستان
https://www.dropbox.com/s/7u5tnet451k3gk3/Ansible.pdf?dl=0
#ansible @unixmens
https://www.dropbox.com/s/7u5tnet451k3gk3/Ansible.pdf?dl=0
#ansible @unixmens
Dropbox
Ansible.pdf
Shared with Dropbox
Forwarded from Academy and Foundation unixmens | Your skills, Your future (yashar esmaildokht 🐧)
مفهوم و ساختار Ansible چیست ؟
چنانچه شما بعنوان یک Linux System Administratior در دیتا سنتری کار کنید میدانید که مدیریت و راهبری تعداد زیاد server کار آسانی نیست مثلا اگر قرار باشد تعداد ۵ تا server را بروز رسانی کنید شاید کار زیاد زمان بری نباشد اما اگر لازم باشد تعداد ۱۰۰ یا ۲۰۰ تا بیشتر را پشتیبانی و بروز رسانی کنید کاری بسیار پر استرس و زمان بر خواهد بود .
در سالهای گذشته بیشتر System Administrator ها از قابلیت نوشت script به منظور راهبری و پشتیبانی server های خود استفاده میکردند که نیاز به دانش عمیق در برنامه نویسی با زبان script داشت و مستلزم وقت برای نوشتن script های صحیح و دقیق و کارا بود . فرض کنید میخواهید کلیه server های خود را update کنید و یا می خواهید backup بگیرید , چنانچه بخواهید بر روی هر server جداگانه این کار را انجام دهید مسلما کاری وقت گیر است که در این زمانه وقت و زمان بسیار در سیستم های آنلاین و برخط مهم است و اینکه server و service شما بالا و برخط باشد و در همان شرایط بتوانید عملیات لازم را روی آن انجام دهید مسئله ای ارزشمند است .
در واقع Ansible یک برنامه opensource برای متمرکز کردن کارهای دیتاسنترها روی server های می باشد . بوسیله Ansible قادر خواهید بود که بسیاری از وظایف ادمین را بصورت خودکار راه اندازی و تعریف کنید تا در زمان مناسب بصورت remote یا از راه دور روی ماشین های شما اجرا گردد. ساختار Ansible بگونه ای طراحی شده است که شما را قادر خواهد ساخت بدون shutdown کردن سیستم به عملیات مختلف روی ماشین های خود ادامه دهید .
مثلا Ansible میتواند عملیاتی مثل update ماشین های مختلف را بصورت Zero Downtime انجام دهد . در ضمن system admin نیازی به نوشتن script های بهینه شده نداشته و میتواند از زبانهای high-level در ansible براحتی استفاده نماید . در Ansible می توانید وظایف را بصورت گروه های مختلف مثلا گروه های مرتبط با host یا نوع آنها و ساختار معماری آنها تعریف نمایید . مفهومی بنام paly در Ansible داریم که مجموع از وظایف مرتبط با یک گروه از host ها را برعهده دارد و فایلی که یک یا بیش از یکی از این palys ها را شامل باشد palybook نامیده می شود . معماری Ansible بصورت agentless است . هر زمانی که Ansible کاری را اجرا کند و فرمانی صادر
کند این کار به ماشین های راه دور منتقل می شود . از آنجاییکه Ansible تعداد زیادی بیش از صد ماژول در core خود دارد لذا کار system administrator ها را خیلی راحت می کند .
در واقع Ansible اولین بار توسط Michael DeHaam طراحی و تولید شد ، شخصی که بوجود آورنده برنامه Collber provisioning بود. از آنجاییکه Ansible بسیار ساده است لذا بسیاری از system admin ها از آن استفاده میکنند . همچنین Developer ها یا توسعه دهندگان برنامه ها نیز می توانند براحتی از Ansible استفاده نمایند زیرا بر پایه زبان Python نوشته شده است . Ansible توسط ابزارهای DevOps مثل Vagrant و Jenkins پشتیبانی می شود. در این بین کارهای زیادی هم وجود دارد که ansible قادر به انجام آنها نیست . مثلا Ansible نمیتواند تغیراتی که توسط کابران در سیستم انجام میگردد را audit یا رسد کند . مثلا اینکه این فایل را چه کسی تغییر داده است .
لیست زیر نمونه ای از کارهایی که توسط Ansible قابل انجام نمی باشد آمده است :
در واقع Ansible می تواند package های مورد نیاز در زمان نصب را اضافه کند، اما قادر به نصب اولیه در حالت minimal روی سیستم نیست . هر سیستمی را میتوان بصورت Minimal راه اندازی کرده و سپس توسط Kickstart یا ابزارهای مشابه یک image از آن تهیه نمود، سپس با Ansible برای پیکربندی های دیگر استفاده کرد .
با اینکه Ansible قادر است پیکربندی مربوط به فایروال را تنظیم نماید اما بر آن نظارتی ندارد . Ansible نمی تواند تغییرات روی فایل های داخل سسیتم را پیگیری کند که آیا این تغییرات توسط کاربر انجام شده یا توسط process . غالبا بهتر است که این گونه تغییرات بهتر است با ابزارهای دیگر مخصوص version control یا ابزارهای audit خود سیستم عامل لینوکس انجام پذیرد.
#ansible #sys_admin #devpos @unixmens
چنانچه شما بعنوان یک Linux System Administratior در دیتا سنتری کار کنید میدانید که مدیریت و راهبری تعداد زیاد server کار آسانی نیست مثلا اگر قرار باشد تعداد ۵ تا server را بروز رسانی کنید شاید کار زیاد زمان بری نباشد اما اگر لازم باشد تعداد ۱۰۰ یا ۲۰۰ تا بیشتر را پشتیبانی و بروز رسانی کنید کاری بسیار پر استرس و زمان بر خواهد بود .
در سالهای گذشته بیشتر System Administrator ها از قابلیت نوشت script به منظور راهبری و پشتیبانی server های خود استفاده میکردند که نیاز به دانش عمیق در برنامه نویسی با زبان script داشت و مستلزم وقت برای نوشتن script های صحیح و دقیق و کارا بود . فرض کنید میخواهید کلیه server های خود را update کنید و یا می خواهید backup بگیرید , چنانچه بخواهید بر روی هر server جداگانه این کار را انجام دهید مسلما کاری وقت گیر است که در این زمانه وقت و زمان بسیار در سیستم های آنلاین و برخط مهم است و اینکه server و service شما بالا و برخط باشد و در همان شرایط بتوانید عملیات لازم را روی آن انجام دهید مسئله ای ارزشمند است .
در واقع Ansible یک برنامه opensource برای متمرکز کردن کارهای دیتاسنترها روی server های می باشد . بوسیله Ansible قادر خواهید بود که بسیاری از وظایف ادمین را بصورت خودکار راه اندازی و تعریف کنید تا در زمان مناسب بصورت remote یا از راه دور روی ماشین های شما اجرا گردد. ساختار Ansible بگونه ای طراحی شده است که شما را قادر خواهد ساخت بدون shutdown کردن سیستم به عملیات مختلف روی ماشین های خود ادامه دهید .
مثلا Ansible میتواند عملیاتی مثل update ماشین های مختلف را بصورت Zero Downtime انجام دهد . در ضمن system admin نیازی به نوشتن script های بهینه شده نداشته و میتواند از زبانهای high-level در ansible براحتی استفاده نماید . در Ansible می توانید وظایف را بصورت گروه های مختلف مثلا گروه های مرتبط با host یا نوع آنها و ساختار معماری آنها تعریف نمایید . مفهومی بنام paly در Ansible داریم که مجموع از وظایف مرتبط با یک گروه از host ها را برعهده دارد و فایلی که یک یا بیش از یکی از این palys ها را شامل باشد palybook نامیده می شود . معماری Ansible بصورت agentless است . هر زمانی که Ansible کاری را اجرا کند و فرمانی صادر
کند این کار به ماشین های راه دور منتقل می شود . از آنجاییکه Ansible تعداد زیادی بیش از صد ماژول در core خود دارد لذا کار system administrator ها را خیلی راحت می کند .
در واقع Ansible اولین بار توسط Michael DeHaam طراحی و تولید شد ، شخصی که بوجود آورنده برنامه Collber provisioning بود. از آنجاییکه Ansible بسیار ساده است لذا بسیاری از system admin ها از آن استفاده میکنند . همچنین Developer ها یا توسعه دهندگان برنامه ها نیز می توانند براحتی از Ansible استفاده نمایند زیرا بر پایه زبان Python نوشته شده است . Ansible توسط ابزارهای DevOps مثل Vagrant و Jenkins پشتیبانی می شود. در این بین کارهای زیادی هم وجود دارد که ansible قادر به انجام آنها نیست . مثلا Ansible نمیتواند تغیراتی که توسط کابران در سیستم انجام میگردد را audit یا رسد کند . مثلا اینکه این فایل را چه کسی تغییر داده است .
لیست زیر نمونه ای از کارهایی که توسط Ansible قابل انجام نمی باشد آمده است :
در واقع Ansible می تواند package های مورد نیاز در زمان نصب را اضافه کند، اما قادر به نصب اولیه در حالت minimal روی سیستم نیست . هر سیستمی را میتوان بصورت Minimal راه اندازی کرده و سپس توسط Kickstart یا ابزارهای مشابه یک image از آن تهیه نمود، سپس با Ansible برای پیکربندی های دیگر استفاده کرد .
با اینکه Ansible قادر است پیکربندی مربوط به فایروال را تنظیم نماید اما بر آن نظارتی ندارد . Ansible نمی تواند تغییرات روی فایل های داخل سسیتم را پیگیری کند که آیا این تغییرات توسط کاربر انجام شده یا توسط process . غالبا بهتر است که این گونه تغییرات بهتر است با ابزارهای دیگر مخصوص version control یا ابزارهای audit خود سیستم عامل لینوکس انجام پذیرد.
#ansible #sys_admin #devpos @unixmens
cl_idc_business_value_ansible_automation_analyst_material_1049194.pdf
1.2 MB
The Business Value of Red Hat Ansible Automation Platform
#ansible #linux #automation
https://t.me/unixmens
#ansible #linux #automation
https://t.me/unixmens
👍1
Academy and Foundation unixmens | Your skills, Your future
GIF
. Injection & Execution
🎯 مفهوم:
در Ansible، تزریق کد زمانی اتفاق می‌افتد که ورودی‌های غیرقابل‌اعتماد (مانند متغیرها، templateها یا URLها) بدون فیلتر و اعتبارسنجی اجرا می‌شوند. این نوع حمله مشابه حملات کلاسیک command injection یا remote code execution (RCE) در برنامه‌های سنتی است.
🚨 مثال خطرناک:
shell: "{{ lookup('env','PAYLOAD') }}"
اگر متغیر PAYLOAD از محیط گرفته شده و بدون اعتبارسنجی استفاده شود، ممکن است دستورات مخرب اجرا شوند.
✅ راهکارها:
از allowlist در متغیرهای پوسته‌ای استفاده کنید (مانند regex برای مجاز کردن فقط دستورات خاص).
فقط از مسیرهای معتبر برای قالب‌ها استفاده کنید.
از اجرای پویا (dynamic include) بدون اعتبارسنجی URL اجتناب کنید.
گیت را روی commit SHA پین کنید، نه روی master یا main، چون ممکن است تغییر کند.
🔐 ۲. Privilege Escalation
🎯 مفهوم:
وقتی که دستورات Ansible با become: yes یا become_user: root اجرا شوند، ممکن است مهاجم از این مسیر برای به‌دست آوردن دسترسی ریشه (root) در کل زیرساخت استفاده کند، مخصوصاً اگر این دسترسی در کل playbook فعال باشد.
🚨 مثال خطرناک:
- name: Restart nginx
become: yes
become_user: root
✅ راهکارها:
فقط در taskهایی که واقعاً نیاز دارند become را فعال کنید.
در فایل ansible.cfg تنظیمات become را محدود کنید.
به جای استفاده از root، از سرویس‌اکانت‌های محدود (مثلاً فقط برای restart کردن nginx) استفاده کنید.
در محیط‌های ابری مانند AWS، از IAM roleهای محدود و موقتی (STS) بهره ببرید.
🧾 ۳. Hardcoded Secrets
🎯 مفهوم:
قرار دادن رمزها و توکن‌ها به صورت واضح در playbookها، ریسک درز اطلاعات محرمانه را به شدت افزایش می‌دهد، مخصوصاً در مخازن عمومی یا زمانی که چند نفر به مخزن دسترسی دارند.
🚨 مثال خطرناک:
vars:
db_password: 'SuperSecret123'
✅ راهکارها:
استفاده از ansible-vault برای رمزنگاری متغیرها.
استفاده از Vaultهای خارجی مانند:
HashiCorp Vault با lookup plugin.
AWS SSM Parameter Store یا AWS Secrets Manager.
رمزها را به صورت inline token استفاده نکنید مگر اینکه عمر کوتاه داشته باشند.
از AppRole و Vault Agent استفاده کنید تا رمزها در حافظه Ansible ظاهر نشوند.
خلاصه :
۱. Injection & Execution
حمله از طریق تزریق کد و اجرای آن
مهاجم میتواند از نقش‌های تأییدنشده، قالب‌ها، ماژول‌های ابری و متغیرها سوءاستفاده کند.
اجرای کد از طریق متغیرهای تزریقی مانند {{ lookup('env','PAYLOAD') }} یا include_tasks: "{{ lookup('url', item) }}".
راهکارها:
استفاده از لیست‌های مجاز (allowlist) برای دستورات شل.
رندر کردن قالب‌ها فقط از مسیرهای ثابت.
محدود کردن داده‌های خارجی، جلوگیری از poisoning.
پین کردن منابع گیت به commit SHA به جای master branch.
۲. Privilege Escalation
ارتقاء سطح دسترسی
استفاده نادرست یا بیش‌ازحد از become: yes یا become_user: root باعث دسترسی ریشه‌ای در محیط می‌شود.
راهکارها:
استفاده از become فقط در سطح task نه در کل playbook.
محدود کردن در ansible.cfg.
استفاده از حساب‌های کاربری با کمترین سطح دسترسی.
استفاده از AWS IAM roles با دسترسی موقت.
۳. Hardcoded Secrets
قراردادن رمزها و اطلاعات حساس در متن ساده
اطلاعاتی مانند رمز دیتابیس یا توکن API نباید به‌صورت hardcode ذخیره شوند.
راهکارها:
استفاده از ansible-vault برای رمزگذاری رمزها.
استفاده از lookupهایی مانند HashiCorp Vault یا AWS SSM برای دریافت اطلاعات در زمان اجرا.
اجتناب از انتقال توکن‌ها به صورت مستقیم در playbook.
#security #devops #ansible
@unixmens
🎯 مفهوم:
در Ansible، تزریق کد زمانی اتفاق می‌افتد که ورودی‌های غیرقابل‌اعتماد (مانند متغیرها، templateها یا URLها) بدون فیلتر و اعتبارسنجی اجرا می‌شوند. این نوع حمله مشابه حملات کلاسیک command injection یا remote code execution (RCE) در برنامه‌های سنتی است.
🚨 مثال خطرناک:
shell: "{{ lookup('env','PAYLOAD') }}"
اگر متغیر PAYLOAD از محیط گرفته شده و بدون اعتبارسنجی استفاده شود، ممکن است دستورات مخرب اجرا شوند.
✅ راهکارها:
از allowlist در متغیرهای پوسته‌ای استفاده کنید (مانند regex برای مجاز کردن فقط دستورات خاص).
فقط از مسیرهای معتبر برای قالب‌ها استفاده کنید.
از اجرای پویا (dynamic include) بدون اعتبارسنجی URL اجتناب کنید.
گیت را روی commit SHA پین کنید، نه روی master یا main، چون ممکن است تغییر کند.
🔐 ۲. Privilege Escalation
🎯 مفهوم:
وقتی که دستورات Ansible با become: yes یا become_user: root اجرا شوند، ممکن است مهاجم از این مسیر برای به‌دست آوردن دسترسی ریشه (root) در کل زیرساخت استفاده کند، مخصوصاً اگر این دسترسی در کل playbook فعال باشد.
🚨 مثال خطرناک:
- name: Restart nginx
become: yes
become_user: root
✅ راهکارها:
فقط در taskهایی که واقعاً نیاز دارند become را فعال کنید.
در فایل ansible.cfg تنظیمات become را محدود کنید.
به جای استفاده از root، از سرویس‌اکانت‌های محدود (مثلاً فقط برای restart کردن nginx) استفاده کنید.
در محیط‌های ابری مانند AWS، از IAM roleهای محدود و موقتی (STS) بهره ببرید.
🧾 ۳. Hardcoded Secrets
🎯 مفهوم:
قرار دادن رمزها و توکن‌ها به صورت واضح در playbookها، ریسک درز اطلاعات محرمانه را به شدت افزایش می‌دهد، مخصوصاً در مخازن عمومی یا زمانی که چند نفر به مخزن دسترسی دارند.
🚨 مثال خطرناک:
vars:
db_password: 'SuperSecret123'
✅ راهکارها:
استفاده از ansible-vault برای رمزنگاری متغیرها.
استفاده از Vaultهای خارجی مانند:
HashiCorp Vault با lookup plugin.
AWS SSM Parameter Store یا AWS Secrets Manager.
رمزها را به صورت inline token استفاده نکنید مگر اینکه عمر کوتاه داشته باشند.
از AppRole و Vault Agent استفاده کنید تا رمزها در حافظه Ansible ظاهر نشوند.
خلاصه :
۱. Injection & Execution
حمله از طریق تزریق کد و اجرای آن
مهاجم میتواند از نقش‌های تأییدنشده، قالب‌ها، ماژول‌های ابری و متغیرها سوءاستفاده کند.
اجرای کد از طریق متغیرهای تزریقی مانند {{ lookup('env','PAYLOAD') }} یا include_tasks: "{{ lookup('url', item) }}".
راهکارها:
استفاده از لیست‌های مجاز (allowlist) برای دستورات شل.
رندر کردن قالب‌ها فقط از مسیرهای ثابت.
محدود کردن داده‌های خارجی، جلوگیری از poisoning.
پین کردن منابع گیت به commit SHA به جای master branch.
۲. Privilege Escalation
ارتقاء سطح دسترسی
استفاده نادرست یا بیش‌ازحد از become: yes یا become_user: root باعث دسترسی ریشه‌ای در محیط می‌شود.
راهکارها:
استفاده از become فقط در سطح task نه در کل playbook.
محدود کردن در ansible.cfg.
استفاده از حساب‌های کاربری با کمترین سطح دسترسی.
استفاده از AWS IAM roles با دسترسی موقت.
۳. Hardcoded Secrets
قراردادن رمزها و اطلاعات حساس در متن ساده
اطلاعاتی مانند رمز دیتابیس یا توکن API نباید به‌صورت hardcode ذخیره شوند.
راهکارها:
استفاده از ansible-vault برای رمزگذاری رمزها.
استفاده از lookupهایی مانند HashiCorp Vault یا AWS SSM برای دریافت اطلاعات در زمان اجرا.
اجتناب از انتقال توکن‌ها به صورت مستقیم در playbook.
#security #devops #ansible
@unixmens