Bu soru sorulduğundan beri Docker'da çok şey değişti, işte güncellenmiş bir cevap için bir deneme.
Öncelikle, özellikle bulutun içinde zaten çalışan konteynerler üzerindeki AWS kimlik bilgileriyle, Vor'un önerdiği gibi IAM rollerini kullanmak gerçekten iyi bir seçenek. Bunu yapabilirseniz, cevabına bir artı bir daha ekleyin ve geri kalanını atlayın.
Bulut dışında bir şeyler çalıştırmaya başladığınızda veya farklı türde bir sırrınız olduğunda, sır saklamaya karşı önerdiğim iki önemli yer vardır :
Ortam değişkenleri: Bunlar bir kapsayıcıda tanımlandığında, kapsayıcı içindeki her işlem bunlara erişebilir, / proc aracılığıyla görülebilirler, uygulamalar ortamlarını günlüklerde depolandığı stdout'a atabilir ve en önemlisi, içinde görünürler. kabı incelerken metni temizle.
Görüntünün kendisinde: görüntüler genellikle birçok kullanıcının çekerek erişebildiği, bazen görüntüyü çekmek için herhangi bir kimlik bilgisi gerekmeden kayıt defterlerine gönderilir. Sırrı bir katmandan silseniz bile, görüntü gibi yaygın Linux yardımcı programlarıyla demonte edilebilir tarve sır, görüntüye ilk eklendiği adımdan bulunabilir.
Peki Docker konteynerlerinde sırlar için başka hangi seçenekler var?
Seçenek A: Bu sırra yalnızca görüntünüzün oluşturulması sırasında ihtiyacınız varsa, sırrı derleme başlamadan önce kullanamıyorsanız ve henüz BuildKit'e erişiminiz yoksa, çok aşamalı bir derleme kötü seçeneklerin en iyisidir. Sırrı, yapının ilk aşamalarına eklersiniz, orada kullanırsınız ve ardından bu aşamanın çıktısını yayın aşamanızın sırrı olmadan kopyalarsınız ve yalnızca bu sürüm aşamasını kayıt sunucularına aktarırsınız. Bu sır hala yapı sunucusundaki görüntü önbelleğinde, bu yüzden bunu yalnızca son çare olarak kullanma eğilimindeyim.
Seçenek B: Ayrıca, derleme süresi boyunca, 18.09'da piyasaya sürülen BuildKit'i kullanabiliyorsanız, şu anda tek bir RUN hattı için bir birim bağlama olarak sırların enjeksiyonuna izin veren deneysel özellikler bulunmaktadır. Bu bağlama, görüntü katmanlarına yazılmaz, bu nedenle, derleme sırasında gizli bilgilere, genel bir kayıt sunucusuna gönderileceğinden endişelenmeden erişebilirsiniz. Ortaya çıkan Dockerfile şuna benzer:
# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...
Ve bunu 18.09 veya daha yeni bir komutla inşa edersiniz:
DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .
Seçenek C:Swarm Modu veya başka bir düzenleme olmadan tek bir düğümdeki çalışma zamanında, kimlik bilgilerini salt okunur bir birim olarak bağlayabilirsiniz. Bu kimlik bilgilerine erişim, docker dışında aynı kimlik bilgileri dosyasına sahip olacağınız erişimin aynısını gerektirir, bu nedenle docker olmadan senaryodan daha iyi veya daha kötü değildir. En önemlisi, kapsayıcıyı incelediğinizde, günlükleri görüntülediğinizde veya görüntüyü bir kayıt defteri sunucusuna gönderdiğinizde bu dosyanın içeriği görünmemelidir, çünkü birim her senaryoda bunun dışındadır. Bu, konteynırın dağıtımından ayrı olarak, kimlik bilgilerinizi docker ana bilgisayarına kopyalamanızı gerektirir. (Unutmayın, docker API'ye erişim ana bilgisayarda kök olduğundan ve kök herhangi bir kullanıcının dosyalarını görüntüleyebileceğinden, bu ana bilgisayarda kapsayıcıları çalıştırma becerisine sahip olan herkes kimlik bilgilerinizi görüntüleyebilir. ,
Bir için docker runbu şuna benzer:
docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image
Veya bir oluşturma dosyası için şunlara sahip olursunuz:
version: '3'
services:
app:
image: your_image
volumes:
- $HOME/.aws/credentials:/home/app/.aws/credentials:ro
Seçenek D:Swarm Mode ve Kubernetes gibi düzenleme araçlarıyla, artık bir ciltten daha iyi sır desteğine sahibiz. Swarm Modu ile, dosya yönetici dosya sisteminde şifrelenir (şifre çözme anahtarı da genellikle oradadır ve yöneticinin şifre çözme anahtarı girmeden yöneticinin yeniden başlatılmasına izin verir). Daha da önemlisi, sır yalnızca sırra ihtiyaç duyan işçilere gönderilir (bu sır ile bir konteyner çalıştırılır), yalnızca çalışan belleğe kaydedilir, hiçbir zaman diskte saklanmaz ve kapsayıcıya tmpfs ile bir dosya olarak enjekte edilir. montaj. Sürü dışındaki ana bilgisayardaki kullanıcılar bu sırrı doğrudan kendi kapsayıcılarına bağlayamazlar, ancak docker API'sine açık erişimle, sırrı düğümdeki çalışan bir kapsayıcıdan çıkarabilirler, bu nedenle yine API. Oluşturmaktan bu gizli ekleme şuna benzer:
version: '3.7'
secrets:
aws_creds:
external: true
services:
app:
image: your_image
secrets:
- source: aws_creds
target: /home/user/.aws/credentials
uid: '1000'
gid: '1000'
mode: 0700
docker swarm initTek bir düğüm için ile sürü modunu açarsınız , ardından ek düğümler eklemek için talimatları izleyin. Sırrı harici olarak oluşturabilirsiniz docker secret create aws_creds $HOME/.aws/credentials. Ve oluşturma dosyasını docker stack deploy -c docker-compose.yml stack_name.
Sırlarımı genellikle şu adresten bir komut dosyası kullanarak değiştiririm: https://github.com/sudo-bmitch/docker-config-update
Seçenek E: Sırları yönetmek için başka araçlar da var ve benim favorim Vault'dur çünkü otomatik olarak sona eren zaman sınırlı sırlar oluşturma yeteneği verir. Her uygulama daha sonra gizli diziler istemek için kendi belirteç setine sahip olur ve bu belirteçler onlara kasa sunucusuna ulaşabildikleri sürece bu sınırlı sırları talep etme yeteneği sağlar. Bu, ağınızdan bir sır çıkarılırsa, işe yaramayacağı veya süresinin dolması hızlı olacağı için riski azaltır. AWS for Vault'a özgü işlevsellik https://www.vaultproject.io/docs/secrets/aws/index.html adresinde belgelenmiştir.