Gizli Bilgileri Yönetin

Fork’lar hakkında asıl nokta şu: bunlar şifreli görüntünün bayt bayt kopyalarıdır, kimlik bilgileriyle birlikte. Depo içinde duran bir Stripe canlı anahtarı, bir veritabanı parolası, bir API token’ı? Fork bunları devralır. Sandbox’ınız gerçek müşteri kartlarını ücretlendirmeye başlar.

Doğru yer rdc repo secret’tır. İki iletim modu, tasarım gereği yalnızca yazılabilir ve fork boş başlar. Bu öğreticide her iki türü de ayarlıyoruz, bunları kullanan bir uygulama dağıtıyoruz, değerlerin container’a gerçekten ulaştığını kanıtlıyoruz, ardından gizli bilgiler fork’u takip etmeyi reddedince fork’un başlamadığını izliyoruz.

Öğreticiyi izleyin

Tuzak: depodaki .env

Çoğu ekip .env dosyasını depoya koyar. Bariz tercih bu.

Sonra fork alırlar.

Fork, üst görüntünün bayt bayt kopyasıdır. .env’de ne varsa fork’un .env’sinde de vardır. Fork’un container’ları başlar. Aynı Stripe anahtarını okurlar. Üretim kimlik bilgileriyle aynı Stripe API’ını çağırırlar. Stripe tarafından bakıldığında, o çağrı sizden gelmiştir.

Bu kötü bir gün demektir. Bana nasıl bildiğimi sor.

Adım 1: env modunda gizli bilgi ayarlayın

rdc repo secret set --name my-app --key DB_HOST --value postgres.internal --mode env

--mode env değerin container içinde ortam değişkeni olarak gelmesini sağlar. İlk yazışlar için ek bir şey gerekmez; yalnızca mevcut bir gizli bilgiyi geçersiz kılmak için o anki değerin kanıtı istenir.

Adım 2: file modunda gizli bilgi ayarlayın

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_xxx --mode file

file modu, değeri container’ın ortamına hiçbir zaman koymaz. Docker’ın standart mekanizmasını kullanarak /run/secrets/stripe_key yoluna yazar. Hassas her şey için bunu tercih edin.

Adım 3: Neler ayarladığınızı listeleyin

rdc repo secret list --name my-app

Adları ve modları görürsünüz. Değer yok. Liste, kim sorarsa sorsun hiçbir zaman değerleri göstermez.

Compose’a bağlayın

docker-compose.yml’yi açın. Her iki moda da başvurun:

services:
  api:
    image: myapp:latest
    environment:
      DATABASE_HOST: ${REDIACC_SECRET_DB_HOST}
    secrets:
      - stripe_key

secrets:
  stripe_key:
    file: /var/run/rediacc/secrets/${REDIACC_NETWORK_ID}/STRIPE_KEY

${REDIACC_SECRET_DB_HOST}, env modudur: renet’in compose sarmalayıcısı bunu dağıtım sırasında gizli deponuzdan genişletir.

secrets: bloğu, Docker’ın standart mekanizmasını kullanan file modudur. Host yolu, aynı compose’un hem üst hem de fork’lar için çalışması amacıyla ${REDIACC_NETWORK_ID} kullanır. Her fork’un kendi ağ kimliği vardır.

Geri okuyamazsınız

İşte ilk kez insanları şaşırtan kısım, kendim de dahil olmak üzere.

Adım 4: Get bir özet döndürür

rdc repo secret get --name my-app --key STRIPE_KEY

Bir özet alırsınız. Değeri değil. Değeri döndüren bir bayrak yoktur. Düz metin değeri geri verecek herhangi bir komut da yoktur.

Bu, GitHub Actions modelidir: yalnızca yazılabilir. --current <değer> girerek ön koşulun geçtiğini izleyerek bir gizli bilgiyi bildiğinizi kanıtlayabilirsiniz. Ancak Rediacc’tan değeri söylemesini isteyemezsiniz.

Adım 5: Unutunca döndürün

Değeri kaybettiniz mi? Gözetlemeyin. Döndürün.

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_new --mode file --rotate-secret

--rotate-secret, ön koşulu atlar. Denetim günlüğü bunu bir döndürme olarak işaretler: açık, kasıtlı.

Eski değeri hatırlıyorsanız bunun yerine --current <old-value> ile kanıtlayın. Bu daha güvenli yoldur. Yanlış terminaldeyken veya yanlış makinedeyken beni birden fazla kez yakalamıştır.

Dağıtın ve teslimatı kanıtlayın

Uygulamaya hiç ulaşmayan gizli bilgiler yalnızca şık bir veritabandır. Dağıtın ve her iki teslimat yolunu da kontrol edin.

Adım 6: Her iki gizli bilgiyle dağıtın

rdc repo up --name my-app --machine <machine-name>

Adım 7: env gizli bilgisi ulaştı

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app printenv DB_HOST'

Container postgres.internal yazdırıyor. Uygulama dağıtım anında ortamına genişletilmiş değeri gerçekten aldı.

Adım 8: file gizli bilgisi ulaştı

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app cat /run/secrets/stripe_key'

Ve işte döndürülmüş değer, container içindeki /run/secrets/stripe_key yolundan okunuyor. Yalnızca yazılabilir olma kuralı insanlara ve CLI’a uygulanır; uygulamanız Docker’ın vaat ettiği yerde gerçek düz metni alır.

Fork’un sonuç darbesi

Tuzağı hatırlıyor musunuz? Depoyu fork’layın ve bakın.

Adım 9: Depoyu fork’layın

rdc repo fork --parent my-app --tag test --machine <machine-name>

Adım 10: Fork boş listeleme yapar

rdc repo secret list --name my-app:test

Boş.

Fork’un Stripe anahtarı yok. Veritabanı parolası yok. API token’ı yok. Fork’taki container’lar ${REDIACC_SECRET_STRIPE_KEY}’i işleyemez. /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY yolundaki dosya yoktur.

Fork sizi taklit edemez.

Adım 11: Fork başlamıyor bile

rdc repo up --name my-app:test --machine <machine-name>

Dağıtım kasıtlı olarak başarısız olur: bind source path does not exist: /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY. Gizli dosya fork’un değil, üst deponun ağ kimliği altında yer aldığından Docker bağlamayı reddeder. Bu başarısızlık demoin kendisidir: üretim kimlik bilgileri bir fork’u asla takip etmez, kazara bile.

Test için fork’ta gizli bilgi isterseniz, bunları sandbox değerleriyle açıkça fork üzerinde ayarlayın, örneğin rdc repo secret set --name my-app:test --key STRIPE_KEY --value sk_sandbox_yyy --mode file. Artık fork Stripe sandbox’ına bağlanır ve temiz başlar. Üretim kimlik bilgileri hiçbir zaman üretimi terk etmedi.

Özet

• rdc repo secret, kimlik bilgilerinizi depo görüntüsünün dışına koyar.
• Her iki mod da container’a gerçekten ulaşır: env genişletme ve /run/secrets.
• get bir özet döndürür, değeri asla. Unuttuğunuzda döndürün; gözetlemeyin.
• Fork boş listeler ve üst compose’u başlatamaz bile.

Fork’un takip edemeyeceği gizli bilgiler.

Sonraki: Yedekleme ve Geri Yükleme.