نوشته های Amirhossein Maleki

راه‌اندازی کلاستر Elasticsearch

Amirhossein Maleki — Wed, 29 Oct 2025 15:46:34 +0330

در یکی از سناریوها، تصمیم گرفتم یک کلاستر Elasticsearch راه‌اندازی کنم؛ اما نه با Docker یا ماشین مجازی. هدف ما ایجاد محیطی بود که در عین سادگی، امن، پایدار و کاملاً سازگار با SELinux باشد.انتخابم: Podman روی Rocky Linux — ترکیبی سبک، بدون daemon و مناسب برای سرویس‌های حیاتی.راه اندازی Elasticsearch Clusterچرا کلاستر؟ و چرا سه نود؟Elasticsearch برای معماری توزیع‌شده طراحی شده است. اما در حالت تک‌نودی نه مقیاس‌پذیری دارد و نه تحمل خطا.در یک محیط چندنودی:داده‌ها به‌صورت shard و replica بین نودها پخش می‌شوند.خرابی یک نود باعث از کار افتادن سرویس نمی‌شود.ایندکس‌گذاری و query به‌صورت موازی انجام می‌شوند.از سه نود استفاده کردم: یک نود master و دو نود data. این ترکیب حداقل ساختاری است که quorum را تضمین می‌کند؛ یعنی اگر یکی از نودها از دسترس خارج شود، دو نود دیگر همچنان قادر به ادامه کار و حفظ هماهنگی هستند.در محیط‌های تولیدی بزرگ‌تر، داشتن سه master اختصاصی و چند data node مجزا توصیه می‌شود.امنیت و TLS بین نودهااولین گام، فعال‌سازی ارتباط امن بین نودهاست. برای این کار از ابزار داخلی elasticsearch-certutil استفاده کردم تا برای هر نود گواهی و کلید اختصاصی تولید شود:bin/elasticsearch-certutil cert --silent --pem \ --in config/instances.yml \ --ca-cert config/certs/ca/ca.crt \ --ca-key config/certs/ca/ca.key \ --out config/certs/certs.zip unzip config/certs/certs.zip -d config/certs/فایل instances.yml باید شامل IP و نام هر نود باشد:instances: - name: "master-node" ip: [""] - name: "data-node-01" ip: [""] - name: "data-node-02" ip: [""]نتیجه: هر نود گواهی و کلید مخصوص خود را دارد، در حالی‌که همه از یک CA مشترک استفاده می‌کنند.پیکربندی نود Mastercluster.name: es-cluster node.name: master-node discovery.seed_hosts: ["", "", ""] cluster.initial_master_nodes: ["master-node"] network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 xpack.security.enabled: true # HTTP TLS xpack.security.http.ssl.enabled: true xpack.security.http.ssl.key: certs/master-node/key.pem xpack.security.http.ssl.certificate: certs/master-node/crt.pem xpack.security.http.ssl.certificate_authorities: ["certs/ca/ca.crt"] # Transport TLS xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.key: certs/master-node/key.pem xpack.security.transport.ssl.certificate: certs/master-node/crt.pem xpack.security.transport.ssl.certificate_authorities: ["certs/ca/ca.crt"] xpack.security.transport.ssl.verification_mode: certificate node.roles: [ master, data, ingest ]در این سناریو به دلیل محدودیت منابع، master نقش data و ingest را هم دارد. در محیط‌های production این نقش‌ها باید از هم جدا باشند.SELinux و مجوزها در Rocky LinuxPodman به‌طور پیش‌فرض با SELinux سازگار است. اگر context فایل‌ها اشتباه باشد، کانتینرها نمی‌توانند به config یا cert دسترسی پیدا کنند.sudo chcon -t container_file_t ~/es-config/elasticsearch.yml sudo chcon -R -t container_file_t ~/es-certs sudo chmod 644 ~/es-config/elasticsearch.yml sudo chmod -R 755 ~/es-certs sudo chown -R $(whoami):$(whoami) ~/es-config ~/es-certsاجرای Elasticsearch با Podmanpodman volume create es-data podman run -d --name elasticsearch \ --network=host \ --security-opt label=disable \ -v es-data:/usr/share/elasticsearch/data \ -v ~/es-config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro \ -v ~/es-certs:/usr/share/elasticsearch/config/certs:ro \ docker.io/library/elasticsearch:8.12.0 sleep 60 && podman logs -f elasticsearchنکته: در محیط‌های امن‌تر، بهتر است به‌جای network=host-- از شبکه جداگانه (bridge یا CNI) استفاده شود.اتصال Kibana با Service Tokenبه‌جای ذخیره رمز عبور کاربر در فایل پیکربندی، از Service Token استفاده کردم:TOKEN=$(curl -s -k -u elastic: -X POST \ "https://:9200/_security/service/elastic/kibana/credential/token/kibana-svc" \ -H "Content-Type: application/json" | jq -r .value)و سپس در فایل kibana.yml:elasticsearch.hosts: ["https://:9200"] elasticsearch.serviceAccountToken: "$TOKEN" elasticsearch.ssl.certificateAuthorities: ["/usr/share/kibana/config/certs/ca/ca.crt"] server.ssl.enabled: true server.ssl.certificate: /usr/share/kibana/config/certs/master-node/master-node.crt server.ssl.key: /usr/share/kibana/config/certs/master-node/master-node.keyاجرای Kibana:podman run -d --name kibana \ --network=host \ --security-opt label=disable \ -v ~/kibana-config/kibana.yml:/usr/share/kibana/config/kibana.yml:ro \ -v ~/es-certs:/usr/share/kibana/config/certs:ro \ docker.io/library/kibana:8.12.0پیکربندی نودهای Datanode.name: data-node-01 node.roles: [ data, ingest ] xpack.security.http.ssl.key: certs/data-node-01/key.pem xpack.security.http.ssl.certificate: certs/data-node-01/crt.pem ES_JAVA_OPTS: "-Xms2g -Xmx2g"نام نود و مسیر گواهی باید دقیقاً با فایل instances.yml یکسان باشد.تنظیمات حیاتی سیستم و JVMsysctl -w vm.max_map_count=262144 ulimit -n 65535در elasticsearch.yml:cluster.routing.allocation.disk.watermark.low: 85% cluster.routing.allocation.disk.watermark.high: 90%و برای حافظه JVM:ES_JAVA_OPTS="-Xms2g -Xmx2g"قانون کلی: حداکثر نیمی از RAM سیستم و حداکثر 32GB برای heap.نکات نگهداری و عملیاتSnapshots به S3 یا فایل‌سیستم خارجی برای Disaster RecoveryMonitoring با X-Pack یا Prometheus ExporterRolling Restart — همیشه نودها را یکی‌یکی بازنشانی کنیدILM برای مدیریت چرخه عمر شاخص‌ها و کنترل رشد حجمAllocation Awareness در محیط‌های چند zone یا چند hostاجرا شد. Podman در این سناریو جایگزین قابل اتکایی برای Docker بود، با کنترل امنیتی بهتر و سازگاری بیشتر در محیط‌های Enterprise.برای تیم‌هایی که به دنبال ترکیبی از سادگی، امنیت و پایداری هستند، Elasticsearch + Podman + Rocky Linux می‌تواند معماری‌ای پایدار و منعطف بسازد.#Elasticsearch #Podman #DevOps #Security #Linux #RockyLinux #SystemDesign #Infrastructure #Kibana #Containers

امنیت کانتینرها و مدیریت سیکرت‌ها در زیرساخت‌های مدرن: یک بررسی عمیق با تمرکز بر Jenkins و HashiCorp Vault

Amirhossein Maleki — Sat, 04 Oct 2025 09:51:28 +0330

چکیدهدر اکوسیستم‌های ابری مبتنی بر میکروسرویس و کانتینر، که با ابزارهایی مانند Docker و Kubernetes مدیریت می‌شوند، امنیت یک الزام مهندسی غیرقابل اجتناب است. طبق گزارش State of Kubernetes Security 2024 از Red Hat، ۹۰٪ سازمان‌ها حداقل یک حادثه امنیتی مرتبط با Kubernetes را تجربه کرده‌اند، و دو سوم تیم‌ها به دلیل نگرانی‌های امنیتی، استقرار را به تأخیر می‌اندازند. همچنین، گزارش Cloud Native Security 2024 از CNCF نشان می‌دهد که میانگین هزینه یک نقض امنیتی در محیط‌های کانتینری به ۴.۸۸ میلیون دلار می‌رسد، شامل جریمه‌های قانونی، خسارت برند و هزینه‌های بازسازی.مدیریت سیکرت‌ها – داده‌های حساسی مانند کلیدهای API، اعتبارهای پایگاه داده و گواهی‌های TLS – یکی از نقاط ضعف کلیدی است. این مقاله، بر پایه تجربیات عملی بیش از یک دهه در مهندسی DevOps، به بررسی چالش‌ها، اشتباهات رایج و راه‌حل‌های عملی برای ایمن‌سازی کانتینرها با استفاده از Jenkins برای CI/CD و HashiCorp Vault برای مدیریت سیکرت‌ها می‌پردازد. هدف، ارائه یک چارچوب مهندسی برای DevOps و SREهاست که امنیت را به عنوان بخشی ذاتی از فرآیند توسعه و استقرار ادغام کنند.ریشه‌یابی: چرا کانتینرها آسیب‌پذیرند؟کانتینرها با استفاده از مکانیزم‌های ایزولاسیون لینوکس مانند namespaces، cgroups و seccomp طراحی شده‌اند، اما این فناوری‌ها به تنهایی در برابر تهدیدات واقعی کافی نیستند. طبق چارچوب MITRE ATT&CK for Containers، تکنیک‌هایی مانند T1610 (Container Breakout) و T1552 (Unsecured Credentials) در بیش از ۶۰٪ حملات موفق نقش دارند. دلایل اصلی آسیب‌پذیری عبارتند از:۱. محدودیت‌های ایزولاسیون ذاتیNamespaces و cgroups منابع (CPU، حافظه، شبکه) را جداسازی می‌کنند، اما بدون سخت‌سازی امنیتی (مانند seccomp profiles یا AppArmor)، یک فرآیند مخرب می‌تواند از کانتینر فرار کند و به میزبان یا سایر کانتینرها دسترسی یابد.مثال عملی: در یک پروژه، یک آسیب‌پذیری در یک dependency (CVE-2025-34203) به مهاجم اجازه داد از طریق syscallهای غیرمجاز به سطح root میزبان برسد.۲. سیکرت‌ها: نقطه مرکزی حملهذخیره‌سازی نادرست سیکرت‌ها (مانند قرار دادن DB_PASSWORD در Dockerfile) باعث می‌شود با ابزارهایی مانند docker inspect یا اسکنرهای GitHub قابل استخراج باشند.گزارش GitGuardian 2025 نشان می‌دهد که ۸ میلیون سیکرت در مخازن عمومی Git نشت کرده‌اند، که ۷۰٪ آن‌ها متغیرهای محیطی در Dockerfile یا env. بودند.عواقب: دسترسی زنجیره‌ای به منابع ابری، دیتابیس‌ها یا حتی کل cluster.۳. تضاد فرهنگی در DevOpsبسیاری از تیم‌ها امنیت را به عنوان مانعی برای سرعت می‌بینند، در حالی که معیارهای DORA (DevOps Research and Assessment) نشان می‌دهند تیم‌هایی با ادغام DevSecOps نه تنها ایمن‌ترند، بلکه تا ۲ برابر فرکانس استقرار بالاتری دارند.مشکل اصلی: فرآیندهای امنیتی اغلب به عنوان یک "add-on" پس از استقرار در نظر گرفته می‌شوند، نه بخشی از pipeline.اصول مهندسی امنیت کانتینر: Defense-in-Depth در عملبرای ایجاد زیرساخت‌های مقاوم، باید یک رویکرد لایه‌لایه (Defense-in-Depth) پیاده‌سازی شود که شکست یک لایه توسط لایه‌های دیگر جبران شود. این اصول در پروژه‌های واقعی تا ۷۰٪ نرخ حوادث را کاهش داده‌اند:۱. اصل حداقل دسترسی (Least Privilege)پیاده‌سازی:در Dockerfile: استفاده از USER 1000:1000 و تنظیم مالکیت با chown -R 1000:1000 /app.در Docker runtime: اعمال cap-drop=ALL --cap-add=NET_BIND_SERVICE,CHOWN-- برای محدودسازی syscallها.استفاده از securityContext در Kubernetes:securityContext: runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"]۲. Image Hardeningاستراتژی‌ها:انتخاب پایه‌های مینیمال مانند alpine:3.20یا gcr.io/distroless/static (بدون shell).استفاده از multi-stage builds برای حذف ابزارهای build-time (مانند compilers).اسکن با ابزارهایی مانند Trivy و Dockle:# Scan for CVEs trivy image --vuln-type os,library --severity CRITICAL,HIGH --exit-code 1 myapp:latest # Audit best practices dockle --exit-code 1 myapp:latest۳. به‌روزرسانی و مدیریت پچ‌های مستمرپیاده‌سازی:Pipeline خودکار برای rebuild ایمیج‌ها با base images به‌روز (cron job هفتگی).ادغام Dependabot یا Renovate برای auto-PR وابستگی‌ها.استفاده از image digests به جای tags برای pinning دقیق:FROM alpine@sha256:abc123...در محیط‌های بزرگ، از registryهایی مانند Harbor با policyهای quarantine برای ایمیج‌های قدیمی استفاده کنید.۴. اسکن آسیب‌پذیری‌ها و تحلیل استاتیکپیاده‌سازی:ادغام Trivy در CI/CD:trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest.ترکیب با SAST (Semgrep) و DAST (OWASP ZAP) برای کد و runtime.۵. ایزولاسیون شبکه‌ای و کنترل دسترسیپیاده‌سازی:در Docker:docker network create --internal mynetدر Kubernetes:apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: app spec: podSelector: {} policyTypes: - Ingress - EgressService Mesh مانند Istio برای mTLS و rate limiting.کاربردی: ابزارهای eBPF مانند Cilium برای monitoring در real-time، با کاهش ۳۰٪ false positives در تشخیص anomalyها.مدیریت سیکرت‌ها: اشتباهات رایج و تحلیل فنیمدیریت نادرست سیکرت‌ها، منبع بیش از ۶۰٪ نقض‌های امنیتی است. اشتباهات رایج:ذخیره در ایمیج: متغیرهای ENV در Dockerfile، که با docker history یا strings image.tar قابل استخراج‌اند.فایل‌های محلی: .env یا config files در Git، که با اسکنرهایی مانند GitGuardian شناسایی می‌شوند.CI/CD ناامن: سیکرت‌ها در Jenkinsfile بدون masking، که در logs قابل رویت‌اند.عدم rotation: سیکرت‌های ثابت ماه‌ها بدون تغییر می‌مانند، که در صورت نشت، زمان کافی برای pivot به مهاجم می‌دهد.HashiCorp Vault: چارچوب مهندسی برای مدیریت سیکرت‌هاVault یک سیستم توزیع‌شده client-server است که برای محیط‌های پیچیده طراحی شده. ویژگی‌های کلیدی:رمزنگاری: داده‌ها با AES-256-GCM ذخیره می‌شوند؛ master key در HSM.سیکرت‌های داینامیک: Engines مانند database برای تولید credentials موقت:vault write database/creds/my-role ttl=5mRBAC با HCL: Policyهای دقیق، مانند:path "secret/data/app/*" { capabilities = ["read", "update"] }Audit و Monitoring: لاگ به Syslog/Splunk برای compliance و forensics.فرآیند: کلاینت (مانند Jenkins) با AppRole یا Kubernetes SA احراز می‌شود، Vault policy را اعمال می‌کند و lease موقت صادر می‌کند. در تولید، از clustering با Consul backend و auto-unseal با AWS KMS استفاده کنید.ادغام Vault با Jenkins: پیاده‌سازی پیشرفته در CI/CDبرای تزریق امن سیکرت‌ها در CI/CD، مراحل زیر پیاده‌سازی می‌شود:نصب پلاگین: HashiCorp Vault Plugin (>=3.0) از Jenkins Plugin Manager.پیکربندی Vault:در Manage Jenkins > Configure System:URL: https://vault.example.com Credential: AppRole with Role ID & Secret ID.احراز هویت:vault write auth/approle/role/jenkins token_ttl=1h secret_id_ttl=2h policies="app-policy".Pipeline امن:pipeline { agent { label 'secure-agent' } environment { VAULT_ADDR = 'https://vault.example.com' } stages { stage('Build and Deploy') { steps { withVault(configuration: [vaultUrl: "${VAULT_ADDR}", vaultCredentialId: 'vault-approle'], vaultSecrets: [[ path: 'secret/data/prod/db', secretValues: [ [envVar: 'DB_USER', vaultKey: 'user'], [envVar: 'DB_PASS', vaultKey: 'pass'] ] ]]) { script { try { sh 'kubectl apply -f deployment.yaml --dry-run=client' sh 'kubectl set env deployment/myapp DB_USER=$DB_USER DB_PASS=$DB_PASS' } catch (Exception e) { echo "Deployment failed: ${e}" error "Aborting due to secret injection failure" } } } } } } post { always { cleanWs() sh 'vault lease revoke -prefix secret/data/prod/db || true' // Revoke leases } } } ویژگی‌ها: Error handling، lease revocation، و cleanup برای جلوگیری از نشت.این Pipeline با Blue Ocean visualization ادغام می‌شود و از credential leaks جلوگیری می‌کند.تزریق سیکرت‌ها در Runtime: رویکردهای Kubernetesبرای runtime، سیکرت‌ها باید بدون ذخیره دائمی تزریق شوند:ایجاد Docker StandaloneDB_USER=$(vault kv get -field=user secret/data/db) DB_PASS=$(vault kv get -field=pass secret/data/db) docker run -d --name app \ -e DB_USER="${DB_USER}" \ -e DB_PASS="${DB_PASS}" \ --network internal-net \ --security-opt no-new-privileges \ myapp:latestKubernetes:Vault Agent Sidecar: Annotationهایی مانند"vault.hashicorp.com/role:app-role" برای تزریق سیکرت‌ها به memory.CSI Driver: Mount سیکرت‌ها به volume بدون sidecar، کاهش overhead.apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: vault-db spec: provider: vault parameters: roleName: "app-role" objects: | - objectName: "db-user" secretPath: "secret/data/db" secretKey: "user"CSI Driver برای scale بزرگ مناسب‌تر است، اما نیاز به تنظیم دقیق RBAC دارد.رخداد امنیتی Tesla در ۲۰۱۸در فوریه ۲۰۱۸، مهاجمان یک Kubernetes Dashboard ناامن در محیط AWS Tesla را کشف کردند که بدون احراز هویت اکسپوز شده بود. این dashboard به مهاجمان اجازه داد به pods دسترسی یابند، AWS credentials را استخراج کنند و منابع را برای cryptomining (Monero) استفاده کنند. گزارش RedLock نشان داد که مهاجمان اسکریپت‌های مخرب را در کانتینرها inject کرده بودند، و credentials استاتیک در محیط کانتینر ذخیره شده بود.تحلیل فنیریشه مشکل:نقض CIS Benchmark ۵.۳.۲: عدم فعال‌سازی احراز هویت برای dashboard.ذخیره credentials استاتیک به جای dynamic secrets.عدم RBAC دقیق: credentials دسترسی کامل به AWS داشتند.عواقب:هزینه‌های محاسباتی بالا (EC2 instances برای mining).ریسک دسترسی به داده‌های حساس Tesla (مانند telemetry خودروها).درس‌های این تجربه:فعال‌سازی MFA و RBAC برای تمام interfaces (مانند Kubernetes Dashboard).استفاده از Vault برای dynamic credentials با TTL کوتاه (مثل ۱۰ دقیقه).اسکن مداوم با ابزارهایی مانند kube-hunter یا Falco برای تشخیص misconfigurations.مانیتورینگ syscallها با Sysdig برای شناسایی رفتارهای غیرعادی.جلوگیری با Vault: اگر Tesla از Vault استفاده می‌کرد، credentials موقت با TTL محدود و RBAC دقیق، دامنه آسیب را به حداقل می‌رساند. Audit logs می‌توانست دسترسی غیرعادی را در real-time تشخیص دهد.بهترین شیوه‌ها: چک‌لیست برای تیم‌های DevOpsNo Secrets in Images: همیشه از dynamic injection با Vault یا external-secrets-operator.Auto-Rotation: Lease revocation خودکار با cron jobs.Least Privilege: RBAC در Vault و Kubernetes با deny-by-default.Monitoring: Audit logs به Prometheus/Splunk با alerting روی access spikes.Hardening: Seccomp profiles سفارشی با security-opt seccomp=profile.json--.Testing: Penetration tests منظم با kube-bench و OWASP ZAP.Runbook عملی: پیاده‌سازی Vault + Jenkins در ۶ گامبرای پیاده‌سازی عملی، این Runbook گام‌به‌گام ارائه می‌شود:نصب Vault:docker run -d --name vault -p 8200:8200 -e 'VAULT_DEV_ROOT_TOKEN_ID=root' hashicorp/vault:1.15 vault secrets enable -path=secret kv-v2 vault kv put secret/data/db user=admin pass=secretpassنصب Jenkins:docker run -d --name jenkins -p 8080:8080 -p 50000:50000 jenkins/jenkins:ltsپیکربندی Vault در Jenkins:در Manage Jenkins > Configure System > Vault:URL: http://host.docker.internal:8200 Credential: Token root.تنظیم AppRole:vault auth enable approle vault write auth/approle/role/jenkins policies="app-policy" token_ttl=1h vault read auth/approle/role/jenkins/role-id vault write -f auth/approle/role/jenkins/secret-idPipeline تست:از کد Jenkinsfile ارائه شده بالاتر استفاده کنید.Hardening برای تولید:TLS برای Vault.Jenkins پشت Nginx با SSO.Auto-rotation برای Secret ID با cron.نگاه انتقادی و آینده‌نگربا وجود ابزارهایی مانند Vault و Jenkins، فرهنگ امنیتی همچنان عقب است. امنیت اغلب به عنوان یک "اضافه‌کاری" دیده می‌شود، در حالی که باید بخشی از DNA pipeline باشد. چالش‌های عملی شامل مدیریت lease در محیط‌های hybrid، scaling Vault clusters و integration با legacy systems است.مسیر آینده:Zero Trust: احراز هویت مداوم با SPIFFE/SPIRE.Ephemeral Secrets: TTL <۱ دقیقه به عنوان استاندارد.Policy as Code: OPA/Gatekeeper برای enforce در GitOps.AI-Driven Security: تشخیص anomalyها با ML برای دسترسی‌های غیرعادی.#DevOps #ContainerSecurity #HashiCorpVault #Jenkins #Kubernetes #CyberSecurity