پیاده‌سازی امنیت صفر و اعتبارهای پویا در OpenShift

در مقاله قبلی، موضوع Secret management را با استفاده از External Secrets Operator (ESO) بررسی کردیم. این نوشته ادامه‌ای بر تکامل DevSecOps است و تمرکز آن بر حذف اسرار طولانی‌مدت و جایگزینی آن‌ها با اعتبارنامه‌های پویا، زودگذر و ایزوله‌سازی شبکه‌ای پیشرفته است. 🛡️

برای معماران و SREهایی که با Red Hat OpenShift کار می‌کنند، هدف این است که خطوط لوله از مصرف‌کننده‌ای که به رمز عبور ثابت تکیه دارد، به موجودیتی با دسترسی Just-In-Time (JIT) تبدیل شود؛ یعنی تنها در زمانی که لازم است، اعتبارنامه‌ها صادر و استفاده شوند.

معماری اعتماد صفر برای خطوط لوله: نمودار منطقی جریان احراز هویت و مجوز بین اجزا را نشان می‌دهد. در این رویکرد هیچ “راز ثابت” برای بار کاری وجود ندارد؛ هویت بار کاری توسط OpenShift ServiceAccount تضمین می‌شود و این ServiceAccount از طریق TokenReview API توسط HashiCorp Vault امضا و تأیید می‌شود.

با OpenShift 4.18 و نسخه‌های جدیدتر، User Defined Networks (UDN) امکان جداسازی کامل لایه 2/3 را برای فضاهای نام حساس به خطوط لوله فراهم می‌کنند. در ادامه یک نمونه مانیفست برای راه‌اندازی شبکه تعریف‌شده توسط کاربر آمده است:

apiVersion: network.openshift.io/v1
kind: UserDefinedNetwork
metadata:
  name: safe-pipeline-net
  namespace: ci-cd-secure
spec:
  topology: Layer3
  layer3:
    role: primary
    subnets:
      - cidr: 10.0.128.0/24
        hostSubnet: 24

درخواست اعتبار موقت با Vault: به جای استفاده از یک راز ایستا، از منبع سفارشی VaultDynamicSecret استفاده می‌کنیم تا External Secrets Operator تنها در صورت نیاز اعتبارنامه‌ها را درخواست کند. برای مثال، خط لوله مهاجرت پایگاه داده که فقط در طول اجرای یک وظیفه به امتیازات DDL نیاز دارد، می‌تواند از این روش بهره ببرد:

generators.external-secrets.io/v1alpha1
kind: VaultDynamicSecret
metadata:
  name: dynamic-db-creds
  namespace: ci-cd
spec:
  # مسیر موتور پایگاه داده در Vault پیکربندی شده است
  path: "database/creds/pipeline-migration-role"
  method: "GET"
  provider:
    server: "http://vault.vault.svc:8200"
    auth:
      kubernetes:
        mountPath: "kubernetes"
        role: "pipeline-role"
        serviceAccountRef:
          name: "pipeline-sa"

مصرف در Tekton: Volume در مقابل env var — اهمیت دارد که هرگز اسرار پویا را به صورت متغیر محیطی (env) تزریق نکنید؛ اگر رمز در طول اجرا بچرخد یا منقضی شود، فرآیند مقدار جدید را نمی‌گیرد. همیشه از volumeMounts استفاده کنید چون Kubernetes فایل‌ها را در حجم به صورت اتمی به‌روزرسانی می‌کند. ⚠️

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: flyway-migration
spec:
  stepTemplate:
    volumeMounts:
      - name: db-creds
        mountPath: /etc/secrets
        readOnly: true
  steps:
    - name: migration
      image: flyway/flyway:latest
      script: |
        #!/bin/sh
        # اعتبارنامه‌های جدید را از سیستم فایل در زمان اجرا می‌خواند
        export FLYWAY_USER=$(cat /etc/secrets/username)
        export FLYWAY_PASSWORD=$(cat /etc/secrets/password)
        flyway -url=jdbc:postgresql://prod-db:5432/mydb migrate
  volumes:
    - name: db-creds
      secret:
        secretName: db-dynamic-secret # ایجاد شده توسط ESO

Reverse sync و PushSecret: در سناریوهای ترکیبی (مثلاً وقتی یک OpenShift داخلی سرویسی در IBM Cloud یا Azure به‌روز می‌کند)، از PushSecret برای انتشار گواهی‌ها یا کلیدهایی که خط لوله تولید می‌کند به یک سرویس خارجی استفاده کنید.

external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: push-generated-cert
  namespace: ci-cd
spec:
  refreshInterval: 10s
  deletionPolicy: Delete
  SecretStoreRefs:
    - name: ibm-secrets-manager
      kind: ClusterSecretStore
  selector:
    secret:
      name: generated-mtls-cert # Secret ایجاد شده توسط خط لوله
  data:
    - match:
        SecretKey: tls.crt
        remoteRef:
          remoteKey: imported-certs/app-cert

زمینه امنیتی و انطباق: برای هماهنگی با Red Hat Advanced Cluster Security for Kubernetes، هر کار باید با حداقل مجوزها اجرا شود. موارد پیشنهادی شامل حذف تمامی capabilities در SecurityContext، اعمال Seccomp profile با RuntimeDefault و تنظیم TTL های کوتاه برای اعتبارنامه‌ها است. نمونه پیکربندی نقش در Vault:

path "database/creds/pipeline-migration-role" {
  capabilities = ["read"]
  ttl = "15m"
  max_ttl = "1h"
}

نتیجه‌گیری: اعتبارنامه‌های پویا در OpenShift مدل امنیتی را از “دفاع محیطی” به “تأیید مداوم” تبدیل می‌کنند. با ترکیب Tekton، External Secrets Operator و User Defined Networks، می‌توان خطوط لوله‌ای ساخت که هیچ راز طولانی‌مدتی ندارند و فقط برای مدت بسیار کوتاهی—حتی میلی‌ثانیه‌ها—اجازه دسترسی می‌گیرند؛ این رویکرد سطح حمله در زنجیره تأمین نرم‌افزار را به‌طور قابل‌توجهی کاهش می‌دهد. 🔑

به گزارش از وبسایت redhat

پیاده‌سازی امنیت صفر و اعتبارهای پویا در OpenShift

لغو پاسخ