Sorry I wrote the reply in English and when I finished I didn't be able to add it so I used the LLM to translate :D my original below in English
تجربتي في إدارة secrets and keys
في تجربتي، استخدمت جميع هذه الخيارات—GitHub Actions Secrets، المتغيرات البيئية (Environment Variables)، HashiCorp Vault، Secret Managers من مزودي السحابة، وKubernetes Secrets—في مشاريع مختلفة. تعلمت أن لا يوجد حل واحد يناسب الجميع، وأن اختيار الأداة يعتمد على سياق المشروع، حجمه، ومتطلبات الأمان.
1. GitHub Actions Secrets
- يجب استخدامها فقط في سير عمل CI/CD، مثل عمليات البناء وعمليات الـ deploy.
- مهم: هذه secrets and keys ليست مخصصة لتمريرها إلى ملفات البناء أو خدمات التشغيل المباشر… نعم، يمكن فعل ذلك، لكن فقط لأغراض POC أو اختبارية وحالات استخدام صغيرة جدًا، وليس للمشاريع في الإنتاج.
- تعمل بشكل جيد عند استخدام GitHub Actions كأداة CI/CD. بالنسبة لأدوات أخرى مثل Jenkins أو GitLab، غالبًا لن تكون GitHub Actions Secrets مناسبة.
2. المتغيرات البيئية (Environment Variables)
- مناسبة للفرق الصغيرة، أو المشاريع التجريبية (POC)، أو النماذج الأولية السريعة.
- سهلة الإعداد والاستخدام.
- غير موصى بها للإنتاج (production)، لأنها تفتقر للأمان، والتدقيق، وقابلية التوسع.
3. Cloud Provider Secret Managers
(مثل: AWS KMS / Secrets Manager، GCP Secret Manager، Azure Key Vault)
خيار قوي لمعظم المشاريع.
المزايا:
سهولة التكامل مع خدمات التخزين والخدمات السحابية، مما يسمح للفرق باستخدام secrets and keys بأمان دون إعداد معقد.
يمكن للفرق إجراء التشفير عند التخزين (at rest) وأثناء النقل (in transit).
على سبيل المثال، لتشفير بيانات قواعد البيانات:
توليد أو استخدام المفتاح الرئيسي (master key) المخزن في KMS أو Vault.
تقوم قاعدة البيانات تلقائيًا بتشفير وفك تشفير البيانات عند القراءة والكتابة.
إذا كنت تستخدم قاعدة بيانات مُدارة من مزود السحابة مثل DynamoDB، يصبح التشفير سهلاً جدًا، ويمكن تخزين المفاتيح وتدويرها بسهولة.
مناسب جدًا للأحمال الإنتاجية، وبيئات متعددة، وتعاون الفرق.
4. HashiCorp Vault
5. Kubernetes Secrets
- مفيد عندما تكون خدماتك مُنشأة داخل cluster في Kubernetes.
- secrets and keys يمكن تحديد نطاقها بحسب المساحات (namespaces)، المراحل (stages)، أو الخدمات، مما يسهل إدارتها داخل الـ cluster.
- يمكن مزامنتها مع Secret Managers في السحابة أو Vault، بحيث تحافظ الفرق على مصدر مركزي للـ secrets and keys مع تمكين الاستخدام داخل الـ cluster.
- مناسب جدًا لهياكل الميكروسيرفيس (microservices) أو النشر متعدد المراحل داخل Kubernetes.
Original reply
My Experience with Managing Secrets
In my experience, I have used all of these options—GitHub Actions Secrets, Environment Variables, HashiCorp Vault, cloud provider Secret Managers, and Kubernetes Secrets—in different projects. I’ve learned that there is no one-size-fits-all solution, and the choice depends on the project’s context, scale, and security requirements.
1. GitHub Actions Secrets
Should be used only for CI/CD workflows, such as build and deploy operations.
Important: They are not meant for passing secrets into build artifacts or runtime services.
Works well when your CI/CD tool is GitHub Actions. For other tools like Jenkins or GitLab, GitHub Secrets are generally not relevant.
2. Environment Variables
Convenient for small teams, proof-of-concepts (POC), or fast prototypes.
Easy to set up and use.
Not recommended for production, as they lack security, auditability, and scalability.
3. Cloud Provider Secret Managers
(e.g., AWS KMS / Secrets Manager, GCP Secret Manager, Azure Key Vault)
- A very solid choice for most projects.
- Advantages:
- Easy integration with cloud storage and services, allowing teams to securely use keys and tokens without extra setup.
- Will allow the team do the encryption at rest and in transit.
- For example for DB level data encryption
- Generating or using a master key (stored in KMS or Vault)
- DB automatically encrypts/decrypts data when writing/reading.
- So if you are using one of the cloud provider DB as managed servicer like dynamoDB you can have this encryption very easy and store your encryption keys easly and rotate them easily
- Works well for production workloads, multi-environment setups, and team collaboration.
4. HashiCorp Vault
Used in projects with complex setups, multiple teams, or multi-project environments, where centralized management of secrets and keys was required.
Strengths:
- Extremely powerful for multi-cloud or highly sensitive environments.
- Supports dynamic secrets, advanced access control policies, and secret rotation.
- Cloud-provider agnostic, avoiding lock-in.
Challenges:
- Requires management and maintenance.
- Adds operational overhead; not recommended for small teams or early-stage projects.
5. Kubernetes Secrets
Useful when your services are deployed inside a Kubernetes cluster.
Secrets can be scoped to namespaces, stages, or services, making them easy to manage inside the cluster.
Can be synced with cloud provider secret managers or Vault, so teams can maintain a central source of truth while still enabling runtime usage inside the cluster.
Best for microservices architectures or multi-stage deployments within Kubernetes.
