Ansult-kasa şifresi nereye yazılır?

Projemizde sızan şifreler veya anahtarların sızmasını önlemek için makul bir kasa kullanmayı planlıyoruz.

Buradaki fikir, tüm hassas verilerimizi düz bir dosyaya koymak ve daha sonra gitmeden önce bir şifre kullanarak bu dosyayı bir kasa kullanarak şifrelemek.

Dosyanın şifresini çözmek için kasa şifresini zorlayabilmemiz gerekiyor, 3 olasılık düşünüyorum:

• Bir sunucu ortam değişkeni içinde saklayın
• Bunu ansible-playbook komutuna seçenek olarak iletin
• Sürüm bilgisi olmayan bir dosyada saklayın.

Kasa kasası şifresini saklamanın en iyi (ve güvenli) yolu olan başka bir seçenek var mı, kasıtlı en iyi uygulama belgeleri bu konuda hiçbir şey söylemiyor.

Fikir tüm hassas verilerimizi koymaktır [...]

Bu cümle içindeki "hepsi" nin anlamı, planladığınız çözümü uygulamadan önce çok dikkatli bir şekilde analiz edilmelidir.

Ansible tonoz çok faydalı bir araçtır, ancak yalnızca aşağıdaki sırları saklamak için kullanılmalıdır:

1. Sorumlu dağıtımlar için özel olarak gerekli
2. Onlardan habersiz olmaları gereken sahipleri için kolayca yararsız hale getirildi, ancak bu yasal olarak onları hatırlayabiliyordu (tipik olarak yerleşik çalışanlar)

İkinci nokta kritik.

Birçok kişi ve potansiyel olarak tüm DevOps ekibi, kasa kasa şifresine ve bu nedenle tüm sırlara erişebilecek.

Bu nedenle, kasada saklanan tüm sırlar için , kendilerine yetkisiz erişimi olan bir kişi veya makinenin , istenirse, bunları kullanamayacak durumda olması gereken bir koşul olmalıdır .

Somut bir ifadeyle, bir veritabanını ve kullanıcılarını dağıtmak için uygun kullanıyorsanız, şifreleri kasada saklayabilirsiniz, ancak bu hizmet İnternet’ten alınabiliyorsa çok dikkatli olmalısınız (ve büyük olasılıkla başka bir çözüm düşünün) ve herhangi bir VPN kimlik doğrulamasına gerek kalmadan!

Sırrına maruz kalan kullanıcılar (DevOps), üzerine bir güvenlik bariyeri uygulandığı takdirde (örneğin, VPN erişimi iptal edildi), "hatırlanan" şifreler kullanamayacak durumda olmalıdır. Buna ek olarak, şifreler değiştirilmeden önce kaynak kod deposuna (kasanın depolandığı) erişim de iptal edilmelidir.

Bu şartlar altında, makul tonoz çok kullanışlı bir araçtır.

İnternette kasada herhangi bir kişi veya makine tarafından kullanılabilecek bir sır saklamaya çalışmak, bunun yerine bir hata olur (örneğin, kullanıcıların VPN bilgileri).

Kasa kasası şifresini saklamanın en iyi (ve güvenli) yolu olan başka bir seçenek var mı?

Önceki paragraftaki koşullar altında, iyi bir uygulamanın olacağını düşünüyorum:

1. Kasa parolasını harici bir güvenli kasada saklayın ( HashiCorp'tan Vault veya kimlik yönetimi için herhangi bir SaaS gibi )
2. Harici kasa öğesine DevOps'a erişim izni verin (test için şifreye ihtiyaç duyacaklar) ve CI / CD sistemi veya denetleyici

3. Sırları kullanmak için bir anlaşma yapın ! Sırlardaki değişiklikleri gözden geçiremezsiniz ve gizli dosyalardaki değişken değişkenleri izleyemezsiniz! Bu yüzden baştan beri titiz olun. Kurallara uygun kasada depolanan tüm değişkenleri secret_önek ile adlandırmak iyi bir kuraldır . Gibi bir şey göreceksiniz:

   postgres.yml:

   postgres_password: "{{ secret_postgres_password }}"
   

   bu değerin Ansible kasasında saklandığını bileceksiniz.

Projemizde sızan şifreler veya anahtarların sızmasını önlemek için makul bir kasa kullanmayı planlıyoruz.

Henüz bir şey uygulamadığınız için, bunu yeniden düşünebilirsiniz. Ansible tonoz gibi bir sistemi kullanmanın bir dizi dezavantajı vardır:

• ulaşmış olduğu hiçbir denetim izi yok
• Bir çalışan ayrıldığında, gizli mağazayı yanlarına almak kolaydır.
• Bir çalışan ayrıldığında erişimlerini kaldırmak, şifreyi değiştirmek ve başkalarına yeniden dağıtmak anlamına gelir.
• tehlikeye atılmış bir Ansible kasa şifresi sonsuza dek kasanın eski bir sürümünde, sürüm kontrolünde saklandığı gibi kullanılabilir.
• sırlar statik olmalı

Potansiyel olarak çok daha güvenli, daha karmaşık olsa da, bu dezavantajları olmayan sistem, sırlarınızı saklamak için Hashicorp Kasası'nı kullanmaktır. Daha sonra https://github.com/jhaals/ansible-vault adresini kullanarak değerleri Ansible kasasından olduğu kadar kolayca çekebilirsiniz .

Öyleyse Hashicorp Vault'a kimlik doğrulamasını yönetmek zorundasınız, bu da kaplumbağa sorusudur . İnsanlar için, en iyi çözümün belirli aralıklarla bir şifre sormak ve belirteci kısa bir süre sonra sona ermek olduğunu düşünüyorum; Makineler için , AWS kimlik doğrulama arka ucunu veya benzerini kullanmak için . Hiçbir yerde bir yerde kimlik doğrulama ihtiyacından asla tamamen kurtulmazsınız, ancak bir saldırganın buna erişim sağlamasını zorlaştırabilirsiniz.

Şimdi, bir gizli sunucu kurmak ve yönetmek sizin için çok fazlaysa, kesinlikle Ansible kasasını kullanabilirsiniz. Şifreyi neden her makinede saklıyorsunuz? Etkileşimli kullanım için, sadece şifreyi isteyebilir ve kullanıcılar kendi tercih ettikleri şifre yöneticisine kaydedebilirler. OS X'teki iTerm, Keychain.app ile entegre olan ve özellikle bunu kolaylaştıran bir şifre yöneticisine sahiptir.

Bu oldukça hassas verilerle ilgili hangi iç politikalara sahip olduğunuzla ilgilidir.

Size bu konudaki yaklaşımımı anlatmak ve artıları ve eksileri olarak gördüğümü açıklamak istiyorum. Ansible Vault şifresini kontrol makinesindeki bir dosyada tutuyorum ve ona işaret eden bir ortam değişkenine sahibim:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

İş istasyonumda (oyun kitaplarını test edip geliştirmem gerektiğine göre) bazı meslektaşlarım da var ve tabii ki ana Ansible kontrol makinesinde var.

Artıları:

• paylaşılan bir yerde / depoda değil (dediğiniz gibi sürümlendirilmemiş bir dosyadır)
• Bir oyun oynamak için Ansible kasa şifrenizi bilmeniz gerekmez (bu, bir CI aracınızın olması şarttır, örneğin, oyun kitaplarını kolayca başlatabileceğiniz Jenkins)

Eksileri:

• şifreyi döndürmek kolay değil
• oynatma kitaplarında çalışan herkesin iş istasyonunda olması gerekiyor

Dezavantajları hafifletiyor, ancak yine de günlük operasyonlarda benimsediğiniz politika ve kurallara bağlı.

Bu projeye göz atın, sizin kasadaki kasanızı şifreleyen şifrelerinizi yönetmek için https://github.com/Smile-SA/ansible-vault-manager

Eklentileri olan birden fazla anahtarlık depolama platformunu yönetmektedir (şimdilik yalnızca AWS SSM uygulanmaktadır). Mevcut bir Ansible projesiyle daha kolay entegrasyon çok kolaydır ...