როგორ მართავთ საიდუმლოებებს CI/CD pipeline-ებში?

Question

Accepted Answer

CI/CD pipeline-ებს სჭირდებათ **საიდუმლოებები** (API გასაღებები, დანერგვის credentials, მონაცემთა ბაზის პароლები, tokens) აგებაში და დანერგვისთვის — მაგრამ მათი არასაიმედო მართვა სერიოზული რისკია. სწორი **საიდუმლოებების მართვა** ინტეგრირებულ პipeline-ში credentials-ის უსაფრთხოობას უზრუნველყოფს.

## პრობლემა: საიდუმლოებები არასოდეს არ უნდა იყოს დაშინებული

```text
Pipelines need credentials, but secrets are a major security risk if mishandled:
  ⚠️ NEVER hardcode secrets in code, pipeline config files, or commit them to Git
     (committed secrets are exposed in history — even if "removed" later)
  ⚠️ NEVER print secrets in logs (pipeline logs may be visible/stored)
→ Leaked CI/CD secrets (deploy keys, cloud credentials) can compromise entire systems.
```

## საიდუმლოებების სწორი მართვა

```text
✓ Use the CI/CD platform's SECRETS STORE — encrypted secrets injected as env vars at
  runtime (GitHub Actions Secrets, GitLab CI variables, etc.) — NOT in the config file
✓ Use dedicated SECRETS MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc.
  (fetch secrets at runtime; centralized, audited, rotatable)
✓ Reference secrets by NAME in the pipeline; the platform injects the value securely:
```

```yaml
# GitHub Actions: reference a secret (stored encrypted in the repo settings)
steps:
  - run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}   # injected securely, not hardcoded, masked in logs
```

## საუკეთესო პრაქტიკა

```text
✓ LEAST PRIVILEGE — pipeline credentials should have only the permissions needed
✓ Prefer short-lived/temporary credentials (e.g. OIDC to assume a cloud role — no
  long-lived keys stored at all)
✓ ROTATE secrets regularly; rotate IMMEDIATELY if leaked
✓ Mask secrets in logs (platforms do this for stored secrets); audit secret access
✓ Separate secrets per environment (dev/staging/prod)
```

## რატომ აქვს მნიშვნელობა

გაკვეთილი იმის შესახებ, თუ როგორ მართოთ საიდუმლოებები CI/CD pipeline-ებში, მნიშვნელოვანია, რადგან **საიდუმლოებების მართვა კრიტიკული უსაფრთხოების საქმეა**, და pipeline-ები მძლავრ credentials-ს მართავენ, რომლებიც, თუ გაჟონდა, შეიძლება გააფუჭოს მთელი სისტემები, ამიტომ ეს აუცილებელი უსაფრთხოების ცოდნაა.

Pipeline-ებს სჭირდებათ საიდუმლოებები (API გასაღებები, დანერგვის credentials, მონაცემთა ბაზის პაროლი) აგებაში და დანერგვისთვის, მაგრამ მათი არასწორი მართვა **სერიოზული, გავრცელებული უსაფრთხოების რისკია**.

ფუნდამენტური წესების გაგება — **არასოდეს არ უნდა hardcode-იყო საიდუმლოებები კოდში ან pipeline კონფიგურაციაში, არასოდეს მათ Git-ში არ უნდა ჩააკმელოთ** (სადაც ისინი დაშინებულია ისტორიაში, თუნდაც მოგვიანებით "გაუსუფთავებელი" იყოს), და **არასოდეს არ უნდა დაბეჭდოთ ისინი logs-ში** — აუცილებელია, რადგან ეს შეცდომები რეალურ, საზიანო credential leaks-ის მიზეზი ხდება (გაჟონილი დანერგვის გასაღებები ან cloud credentials-ი შეიძლება გააფუჭოს მთელი სისტემები).

გაკვეთილი **საიდუმლოებების სწორი მართვის** შესახებ — CI/CD პლატფორმის **დაშიფრული საიდუმლოებების მაცდuria-ს** გამოყენება (საიდუმლოებების ჩასახლება გარემოს ცვლადებად runtime-ში ნაცვლად მათი კონფიგურაციაში შენახვის), სამეზობლო **secrets managers** (Vault, AWS Secrets Manager ცენტრალიზებული, აუდიტირებული, ბრუნვადი საიდუმლოებებისთვის), და საიდუმლოებების მითითება სახელით ისე, რომ პლატფორმა უსაფრთხოდ ჩასახლებს მნიშვნელობებს (და მათ logs-ში ასაფიწა ხდის) — აუცილებელი პრაქტიკული ცოდნაა credentials-ის უსაფრთხოებაში.

გაკვეთილი **საუკეთესო პრაქტიკის** შესახებ — **უმცროსი სამართალი** (pipeline credentials-ით მხოლოდ საჭირო ნებართვები, blast radius შეზღუდვა), **მოკლევადიანი/დროებითი credentials** პრიორიტიზაცია (როგორც OIDC cloud roles-ის ასანთებლად, რთული გასაღებების შენახვის მოშორებით — თანამედროვე საუკეთესო პრაქტიკა), საიდუმლოებების რეგულარული **ბრუნვა** და დაუყოვნებელი ბრუნვა გაჟონილების შემთხვევაში, და საიდუმლოებების გაყოფა გარემოს მიხედვით — აკეთებს მოიმწვევს, უსაფრთხო pipeline პრაქტიკას.

ვინაიდან CI/CD pipeline-ები მძლავრ credentials-ს მართავენ, რომელთა გაჟონვა სისტემებს საფრთხეშ შეუძლია დააყენოს, და ვინაიდან საიდუმლოებების სწორი მართვა (არასოდეს hardcoding/committing/logging საიდუმლოებები, secrets stores/managers-ის გამოყენება, უმცროსი სამართალი და მოკლევადიანი credentials) აუცილებელია სერიოზული დარღვევების თავიდან აცილებაში, გაკვეთილი იმის შესახებ, თუ როგორ მართოთ საიდუმლოებები CI/CD-ში, მნიშვნელოვანია, უსაფრთხოების კრიტიკული ცოდნა უსაფრთხო pipeline-ების აგებაში — მაღალი ხარისხის სფერი, სადაც სწორი პრაქტიკა თავიდან აცილებს credential leaks-ს, რომელიც რეალური, საზიანო რისკია ავტომატიზირებული delivery-ში.