> For the complete documentation index, see [llms.txt](https://docs.kangal.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kangal.dev/tr/production-operasyonlari/secrets.md).

# Secret yönetimi

Üretim gizli bilgilerini yönetilen bir gizli bilgi sisteminden çalışma zamanında dağıtın. Gizli değerleri Git'e, Helm values dosyalarına, Compose override'larına, CI günlüklerine, destek kayıtlarına, sohbetlere, sürüm notlarına, yapılandırma dışa aktarımlarına veya destek paketlerine eklemeyin.

## Gizli bilgi envanteri

Her gizli bilgi sınıfı için sahip, kaynak, tüketiciler, yenileme aralığı ve son yenileme tarihini kaydedin:

| Sınıf                   | Tipik çalışma zamanı anahtarı                                            | Tüketiciler                                      |
| ----------------------- | ------------------------------------------------------------------------ | ------------------------------------------------ |
| Token imzalama          | `SECRET_KEY`                                                             | API ve çalışanlar                                |
| Alan şifreleme          | `FIELD_ENCRYPTION_KEY`                                                   | Şifreli alanları okuyan API ve çalışanlar        |
| MongoDB bağlantısı      | `MONGODB_URL`                                                            | API, çalışanlar ve yedekleme/geri yükleme işleri |
| Redis bağlantısı        | `REDIS_URL`                                                              | API ve çalışanlar                                |
| Kalıcı iş Redis'i       | `KANGAL_BACKGROUND_JOBS_REDIS_URL`                                       | Tüm bölgelerdeki API üreticileri ve çalışanlar   |
| OAuth ve SSO            | Sağlayıcı istemci sırları ve imzalama malzemesi                          | API                                              |
| E-posta                 | `SMTP_USERNAME`, `SMTP_PASSWORD`                                         | API veya e-posta çalışanı                        |
| Sağlayıcı erişimi       | Bulut, gözlemlenebilirlik, yapay zekâ ve entegrasyon kimlik bilgileri    | Gereken API ve çalışanlar                        |
| Veri düzlemi güveni     | Düğüm token'ı, imzalama anahtarı, önbellek anahtarı, istemci sertifikası | Kontrol düzlemi ve seçili veri düzlemi           |
| DR denetleyici quorum'u | `KANGAL_DR_FENCING_CONTROLLERS_JSON`                                     | Her bölgesel kontrol düzlemi                     |

Geliştirme, hazırlık ve üretim için farklı değerler kullanın. Token imzalama, alan şifreleme, veri düzlemi imzalama ve haricî sağlayıcılar gibi ayrı güven sınırlarında aynı değeri yeniden kullanmayın.

## Kubernetes üzerinden dağıtım

Çalışma zamanı Secret'ını external secret controller, CSI sürücüsü veya eşdeğer bir platform entegrasyonuyla oluşturun. Chart'tan mevcut Secret'a başvurun:

```yaml
api:
  extraEnvFrom:
    - secretRef:
        name: kangal-runtime

backgroundJobs:
  enabled: true
  inheritApiExtraVolumes: true
```

Özel CA paketleri, workload identity token'ları veya sağlayıcı kimlik bilgisi dosyaları için `api.extraVolumes` ve `api.extraVolumeMounts` ile projected file kullanın. Çalışanlar varsayılan olarak API volume bağlamalarını devralır. Daha dar bir yetki kümesi gerekiyorsa devralmayı kapatıp yalnızca çalışana ait projection tanımlayın.

Commit edilen values dosyalarında `api.secretEnv` veya `credentials.secrets[].stringData` kullanmayın. Bu alanlara yazılan değerler Helm sürüm durumunda saklanır. Önceden oluşturulmuş Secret referanslarını tercih edin.

Değerleri okumadan adları ve anahtarları doğrulayın:

```bash
kubectl -n "$NAMESPACE" get secret kangal-runtime \
  -o go-template='{{range $key, $value := .data}}{{$key}}{{"\n"}}{{end}}'
kubectl -n "$NAMESPACE" get pod \
  -l app.kubernetes.io/instance="$RELEASE" \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[*].ready}{"\n"}{end}'
```

Rutin doğrulama kanıtı olarak `kubectl get secret -o yaml` çalıştırmayın.

## Başlatma ve güvenli hata davranışı

Üretimde API hem token imzalama sırrını hem de bağımsız bir `FIELD_ENCRYPTION_KEY` değerini zorunlu tutar; bu iki amaç için aynı değeri kullanmayın. MongoDB veya Redis erişilemezse `/ready` `503` döndürür. Ortak Redis zorunlu olacak şekilde yapılandırılan kalıcı işler, özel kuyruk URL'si bulunmadığında başlamayı reddeder. Dağıtım kabulünde kimlik bilgisi yetkilerini, sertifika son kullanma tarihlerini, yedek erişimini ve sağlayıcı erişilebilirliğini ayrıca doğrulayın.

## Saklanan gizli alanlar

Kangal; desteklenen eklenti, vault, entegrasyon, protokol, kimlik ve yapay zekâ yapılandırmalarındaki bilinen gizli alanları kalıcı depolamadan önce şifreler. Genel yönetim yanıtları bu değerleri maskeler. Vault içeriğinde anahtar adları kullanıcı tarafından belirlendiği için tüm skaler değerler maskelenir.

`FIELD_ENCRYPTION_KEY` zorunludur. Aynı şifreli veriyi okuyan bütün replikalar aynı etkin değeri almalıdır; bu değer token imzalama anahtarından ve diğer tüm güven sınırlarından bağımsız olmalıdır. Anahtarı yalnızca kurumun onaylı alan şifreleme prosedürüyle sağlayın ve yenileyin.

## Haricî gizli bilgi referansları

Vault destekli yapılandırma, sağlayıcı değerleri yerine referans saklayabilir:

```
vault://hashicorp/tenants/acme/apps/orders#token
vault://aws/tenants/acme/apps/orders#password
vault://gcp/apps/orders#api_key
vault://azure/tenants/acme/apps/orders#client_secret
vault://conjur/tenants/acme/apps/orders#password
```

Çözümleme tenant kapsamlıdır ve sonuç belirli bir süre Redis'te önbelleğe alınır. Çalışma zamanı kimliğine yalnızca eşlenen tenant yolu için yetki verin. Mümkünse workload identity veya kısa ömürlü projected credential kullanın. Özel sağlayıcı uç noktalarını onaylı HTTPS origin'lerinde tutun ve dış ağ erişimini sınırlandırın.

Referanslar gizli değerin kendisi değildir; ancak sağlayıcı ve nesne yapısını açığa çıkarabilir. Yapılandırma dışa aktarımlarını ve tanılama yapıtlarını hassas metadata olarak yönetin.

## Yenileme prosedürleri

### Token imzalama

1. Gizli bilgi yöneticisinde yeni bir değer üretin.
2. Mevcut anahtarı önceki imzalama anahtarları listesine taşıyıp yeni anahtarı etkinleştirin.
3. API ve çalışan replikalarını kademeli olarak yeniden başlatın.
4. Yeni erişim ve yenileme token'larını doğrulayın; imza hatalarını izleyin.
5. Önceki anahtarı, kabul edilen en uzun token ömrü ve olay için tanımlanan ek süre dolduktan sonra kaldırın.

### Alan şifreleme

Çalışma zamanı tek etkin alan şifreleme anahtarı kullanır. Onaylı yenileme prosedürünü izleyin; anahtarı doğrudan değiştirmeyin. Doğrulanmış yedek alın, prosedürü hazırlık ortamında sınayın, değişiklik penceresinde gizli alan yazmalarını denetim altında tutun, onaylı yeniden şifreleme adımını tamamlayın, okumaları doğrulayın ve ardından yeni anahtarı bütün replikalara dağıtın.

### Veri tabanı ve Redis kimlik bilgileri

Sağlayıcı destekliyorsa çakışan geçerlilik süreleri kullanın: yeni kimlik bilgisini oluşturun, en az yetkiyi verin, çalışma zamanı Secret'ını güncelleyin, iş yüklerini kademeli yeniden başlatın, `/ready` ile çalışan sağlığını doğrulayın ve eski kimlik bilgisini iptal edin. Yedekleme ve geri yükleme kimliklerini ayrı doğrulayın.

### Sağlayıcı, veri düzlemi ve DR kimlik bilgileri

Her güven sınırını bağımsız yenileyin. İlgili entegrasyonu yeniden sınayın. Düğüm güveni değişiyorsa veri düzlemi düğümlerini yeniden kaydedin veya dağıtın. DR denetleyici quorum'unun tam promotion envelope'unu imzalayabildiğini doğrulayın. Denetleyici anahtarlarını veya fence token'larını olay kayıtlarına yapıştırmayın.

## Günlükler ve kanıt

Kangal bilinen gizli alanları ve sürüm denetimi çıktılarını maskeler; operatör komutları ve üçüncü taraf araçlar aynı korumayı uygulamayabilir. Günlük toplayıcılarında Authorization başlıklarını, cookie'leri, bağlantı dizelerini, özel anahtarları ve Kubernetes Secret verilerini temizleyin. Kanıtlar Secret adı, sürüm, zaman damgası, iş yükü revizyonu ve test sonucunu içerebilir; değerleri içermemelidir.

İfşadan şüpheleniyorsanız önce kimlik bilgisini iptal edin, maskelenmiş kanıtı koruyun, türetilmiş veya yeniden kullanılmış tüm kimlik bilgilerini yenileyin, gerekiyorsa oturumları geçersiz kılın ve ifşa zamanından sonraki kullanımlar için denetim kayıtlarını inceleyin.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kangal.dev/tr/production-operasyonlari/secrets.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
