Disclaimer: non-English version of the guide contain unofficial translations contributed by our users. They are not binding in any way, are not guaranteed to be accurate, and have no legal effect. The official text is the English version of the Vault website.
Vault dökümantasyonuna hoş geldiniz! Bu dokümantasyon, Vault'un tüm özellikleri ve yetenekleri için bir referans kaynağıdır. Vault ile bilgi almaya, giriş bölümüyle başlayın ve Başlarken kılavuzuna ile devam edin.
Bu kılavuz, Vault ile başlamak için en iyi yerdir. Vault'un ne olduğunu, hangi problemleri çözebileceğini ve nasıl hızla kullanmaya başlayacağınızı anlatmaktadır.
Vault, gizli kalması gereken verilere(secrets) güvenli bir şekilde erişmek için kullanılan bir araçtır. Bu veriler, API anahtarları, şifreler, sertifikalar vb. erişimini sıkı bir şekilde kontrol etmek istediğiniz herhangi bir şey olabilir. Vault, sıkı erişim kontrolü sağlamak ve detaylı bir denetim günlüğü kaydetmek için bu gizli veri ile bütünleşik bir arayüze sahiptir.
Modern bir sistem, gizli tutulması gereken bir çok veriyi içerir (secrets): Veritabanı kimlik bilgileri, harici hizmetler için API anahtarları, hizmet odaklı mimari iletişimi için kimlik bilgileri gibi gizli bilgilere kimlerin eriştiğini platform spesifik olarak testpit etmek oldukça zordur. Rol tabanlı koruma, güvenli depolama, detaylı denetim günlüklerini yönetme gibi operesyonlar özel bir çözüm olmadan neredeyse imkansızdır. İşte Vault burada devreye girmektedir.
Vault un temel özellikleri şunlardır:
Gizli bilgiler anahtar/değer (key/value) olarak Vaultta saklanabilir. Vault, bu gizli bilgileri kalıcı depolamaya yazmadan önce şifreler; bu nedenle, Gizli verilere erişmek için ham depolamaya erişmek yeterli değildir. Vault verileri diske yazabildiği gibi, depolama için Consul gibi araçlardan da faydalanabilir.
Vault, AWS veya SQL veritabanları gibi bazı sistemler için gizli verileri talep üzerine üretilebilir. Örneğin, uygulamanın bir S3 alanına erişmesi gerektiğinde Vaulta kimlik bilgilerini sorar ve Vault talep üzerine geçerli izinlere sahip bir AWS erişim anahtarı oluşturur. Vault Gizli bilgileri oluşturulduktan sonra, gerektiğinde (kullanım süresi dolduğunda) otomatik olarak iptal işlemini de gerçekleştirir.
Vault, verileri şifreleyebilir ve şifresini çözebilir. Bu, güvenlik ekiplerinin ve geliştiricilerin şifreleme operasyonlarını kendi şifreleme yöntemlerini tasarlamak zorunda kalmadan SQL gibi bir konuma depolamalarını sağlar.
Vault üzerinde barıdırılan her gizli bilginin kullanım süresi vardır. Bu sürenin sonunda, Vault gizli bilgileri otomatik olarak iptal edecektir. Kullanıcılar, yerleşik yenileme API'ları aracılığı ile bu süreyi uzatabilir veya bu gizli erişim bilgilerini yenileyebilir.
Vault, gizli bilgilerin iptalini yerleşik olarak destekliyor. Vault sadece bir tek gizli veriyi değil, aynı zamanda bir gizli veri grubunu iptal edebilir, örneğin tüm Gizli veriler belirli bir kullanıcı tarafından okunabilir. Bu açıdan, iptal işlevi, sistemi kilitlemede önemli rol oynamanın yanı sıra bir saldırı durumunda sistemleri güvence altına almaya da yardımcı olur.
Vault'un kullanım alanlarını anlamadan önce, ne olduğunu bilmek faydalıdır. Bu sayfada Vault için bazı somut kullanım alanları listelenmiştir, ancak muhtemel kullanım alanları, burada anlatılanlardan çok daha fazladır.
Vault en azından gizli bilgilerin depolanması için kullanılabilir. Örneğin; Vault, hassas çevre değişkenleri, veritabanı kimlik bilgileri, API anahtarları vb. verileri depolamak için mükemmel bir araçtır.
Bunu dosyalarda, yapılandırma yönetiminde, veritabanında vb. düz metin olarak depolama yöntemleri ile karşılaştırıldığında, Vault üzerinden okuma veya API'yi kullanarak bu verileri sorgulamak çok daha güvenli olacaktır. Ayrıca Vault bu verilerin düz metin sürümünü ve kayıt defteri erişimini denetim günlüğünde saklanmaktadır.
"Kimlik Bilgileri Depolama Alanı", "Genel Depolama Alanı" ile benzer özellikler barındırır. Vault, çalışanların web hizmetlerine erişmek için paylaştıkları kimlik bilgilerini depolamak için iyi bir mekanizmadır. Denetim günlük mekanizması, çalışanların eriştikleri verilerin ne olduğunu ve bir çalışan ayrıldığında ne yaptığını bilmenizi sağlar ve hangi verilerin devreden çıkarılacağını anlamak daha kolaydır.
Örneğin, Bir komut dizisinin çalışma süresi için, AWS erişim anahtarı oluşturulabilir ve daha sonra iptal edilir. Erişim anahtarları, komut dosyası çalıştırılmadan önce veya sonrasında var olmayacaktır, ancak anahtarların oluşturulması tamamen kayıt altına alınacak, denetim günlüğüne (log dosyalarına) işlenecektir.
Bu özellik, Amazon IAM gibi bir servis kullanmanız söz konusu olduğunda; sınırlı erişim belgelerini etkili bir şekilde oluşturmanızı ve kodunuz üzerinden kullanabilmenizi sağlar.
Gizli bilgilerin depolanabilmesinin yanı sıra, Vault başka yerlerde depolanan verileri şifrelemek ve şifrelerin çözülmesi için kullanılabilir. Bu özellik, uygulamaların verilerini birincil veri deposunda sakladığı halde uygulamaların bu verilerini şifrelemesine izin vermektedir.
Bunun faydası, geliştiricilerin verileri doğru şekilde nasıl şifreleme konusunda endişelenmeleri gerekmemesidir. Şifreleme sorumluluğu Vault'tadır ve geliştiriciler sadece verileri gerektiği gibi şifrelemekte/şifresini çözmektedir.
Önce makinenize Vault kurulmalıdır. Vault, tüm desteklenen platformlar ve mimariler için ikili paket olarak dağıtılır. Bu sayfada Vault kaynağından nasıl derleneceği anlatılmıyor, ancak dosyanın en son kaynak kodundan derlendiğinden emin olmak isteyenler bu belgeye göz atabilir.
Vault yazılımını yüklemek için, sisteminize uygun paketi bulun ve indirin. Vault bir zip dosyası olarak paketlenmiştir.
Vault dosyasını indirdikten sonra paketi açın. Vault, vault adlı tek bir dosya olarak çalışır. Pakette bulunan diğer dosyalar da güvenle silinebilir ve vault'un çalışmasını etkilemez.
Son adım, PATH ortam değişkeninde vault dosyasının adresinin mevcut olduğundan emin olmaktır. Linux ve Mac'te PATH ayarlama ile ilgili talimatlar için bu sayfaya bakın. Windows'ta PATH ayarlama yönergeleri de bu sayfada bulunmaktadır.
Vault'u kurduktan sonra, yeni bir terminal oturumu açarak ve vault dosyasının mevcut olup olmadığını kontrol ederek kurulumun çalıştığını doğrulayın. Vault'u çalıştırarak, aşağıdakine benzer bir yardım çıktısı görmelisiniz:
$ vault
usage: vault [-version] [-help] <command> [args]
Common commands:
delete Delete operation on secrets in Vault
path-help Look up the help for a path
read Read data or secrets from Vault
renew Renew the lease of a secret
revoke Revoke a secret.
server Start a Vault server
status Outputs status of whether Vault is sealed and if HA mode is enabled
write Write secrets or configuration into Vault
All other commands:
audit-disable Disable an audit backend
audit-enable Enable an audit backend
audit-list Lists enabled audit backends in Vault
auth Prints information about how to authenticate with Vault
auth-disable Disable an auth provider
auth-enable Enable a new auth provider
init Initialize a new Vault server
key-status Provides information about the active encryption key
mount Mount a logical backend
mount-tune Tune mount configuration parameters
mounts Lists mounted backends in Vault
policies List the policies on the server
policy-delete Delete a policy from the server
policy-write Write a policy to the server
rekey Rekeys Vault to generate new unseal keys
remount Remount a secret backend to a new path
rotate Rotates the backend encryption key used to persist data
seal Seals the vault server
ssh Initiate a SSH session
token-create Create a new auth token
token-renew Renew an auth token if there is an associated lease
token-revoke Revoke one or more auth tokens
unmount Unmount a secret backend
unseal Unseals the vault server
version Prints the Vault versionEğer dosyanın bulunamadığını belirten bir hata alırsanız, PATH ortam değişkeniniz düzgün kurulmamıştır. Lütfen önceki adıma dönün ve PATH değişkeninizin Vault kurulu olduğu dizini içerdiğinden emin olun.
Aksi takdirde, Vault kurulu ve çalışmaya hazır!
Vault kurulu olduğunda bir sonraki adım Vault sunucusunu başlatılmasıdır.
Vault istemci/sunucu uygulaması olarak çalışır. Vault sunucusu, veri deposu ve servislerle etkileşim kuran Vault mimarisinin tek parçasını oluşturur. Vault CLI aracılığıyla yapılan tüm işlemler, TLS bağlantısı üzerinden sunucu ile etkileşim kurar.
Bu sayfada, sunucunun nasıl başlatıldığını anlamak için Vault sunucusunu başlatacak ve etkileşimde bulunacağız.
İlk olarak, Vault geliştirici sunucusu başlatacağız. Vault geliştirici sunucusu, yerel ortamda Vault ile oynamak için çok güvenli ancak kullanışlı olmayan, önceden yapılandırılmış bir sunucudur. Bu kılavuzun ilerleyen kısımlarında gerçek bir sunucuyu yapılandırıp başlatacağız.
Vault geliştirici sunucusunu başlatmak için şunu çalıştırın:
$ vault server -dev
WARNING: Dev mode is enabled!
In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.
The only step you need to take is to set the following
environment variable since Vault will be talking without TLS:
export VAULT_ADDR='http://127.0.0.1:8200'
The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.
Unseal Key: 2252546b1a8551e8411502501719c4b3
Root Token: 79bd8011-af5a-f147-557e-c58be4fedf6c
==> Vault server configuration:
Log Level: info
Backend: inmem
Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
...Yukarıdaki gibi bir çıktı görmelisiniz. Vault ön planda çalışmaya devam edecek; Daha sonra, farklı komutlar uygulamak için yeni bir terminal açın.
Gördüğünüz gibi, bir geliştirici sunucusu başlattığınızda, Vault sizi yüksek sesle uyarır. Geliştirici sunucusu tüm verilerini belleğe kaydeder (ancak yine de şifrelenmiş), localhost üzerinde TLS dinler ve otomatik olarak açar ve size mühür açılış anahtarını (unseal key) ve kök erişim anahtarını gösterir. Bütün bunların ne anlama geldiğini birazdan gözden geçireceğiz.
Geliştirici sunucusu ile ilgili önemli nokta, yalnızca geliştirme amaçlı olmasıdır.
Not: Geliştirici sunucusunu gerçek bir ortamda (production) çalıştırmayın.
Geliştirici sunucusu gerçek bir ortamda (production) çalıştırıldığında, verileri bellekte depolar ve her yeniden başlatmada tüm gizli verileriniz silineceğinden bunun size pek yararı olmaz.
Geliştirici sunucusunu çalışırken:
-
Yeni bir terminal oturumu açın.
-
export VAULT_ADDR='....komutunu terminal çıktısından kopyalayın ve çalıştırın. Vault istemcisini, geliştirici sunucumuzla konuşacak şekilde yapılandıracaktır. -
Mühür açma anahtarını (unseal key) bir yere kaydedin. Bunu nasıl güvenli bir şekilde saklayacağınız konusunda endişelenmeyin. Şimdilik, herhangi bir yere kaydedin.
-
Adım 3 ile aynı işlemi yapın, ancak
rootanahtarı ile yapın. Bunu daha sonra kullanacağız.
vault status komutunu çalıştırarak sunucunun çalıştığını doğrulayın. Bu başarılı sonuç almalı ve 0 çıkış kodu ile çıkmalıdır. Bağlantı açma konusunda bir hata görürseniz, yukarıdakiexport VAULT_ADDR='.... komutunu düzgün bir şekilde yürüttüğünüzden emin olun.
Başarılı olursa, çıktı aşağıdaki gibi görünmelidir:
$ vault status
Sealed: false
Key Shares: 1
Key Threshold: 1
Unseal Progress: 0
High-Availability Enabled: falseÇıktı farklı görünüyorsa, özellikle sayılar farklıysa veya Vault mühürlenmişse (sealed=true), geliştirici sunucusunu yeniden başlatın ve tekrar deneyin. Bunların farklı olmasının tek nedeni, daha önce bu rehberden bir geliştirici sunucusu çalıştırmamanızdan kaynaklanır.
Bu çıktının daha sonra rehberde ne anlama geldiğini anlatacağız.
Tebrik ederiz! İlk Vault sunucusunu başlattınız. Henüz herhangi bir gizli veri(secret) depolamadık, ancak bunu bir sonraki bölümde yapacağız.
Şimdi geliştirci sunucumuz ayakta ve çalışıyor. İlk gizli verimizi yazıp okuyabiliriz.
Vault'un temel özelliklerinden birisi gizli verilermizi güvenli bir şekilde okuma ve yazma yeteneğidir. Bu sayfada, CLI kullanarak bunu yapacağız, ancak Vault'un yeteneklerinden faydalanabileciğimiz eksiksiz bir HTTP API'si olduğunu bilmekte fayda var.
Vault'a yazılan gizli bilgiler önce şifrelenir daha sonra depolama alanına yazılır. Geliştirici sunucusunda, depolama alanı bellektir, ancak gerçek ortamda büyük olasılıkla disk veya Consul olacaktır. Vault veriyi depolama sürücüsüne teslim edilmeden önce şifreler. Depolama mekanizması şifrelenmemiş veriyi görmez ve Vault olmadan şifresini çözmek için gerekli araçlara sahip değildir.
Hadi ilk gizli verimizi yazalım. Bu işlemi Aşağıda gösterildiği gibi vault write komutuyla yapıyoruz:
$ vault write secret/hello value=world
Success! Data written to: secret/helloBu, eşitlik value=world secret/hello yoluna yazılır. Yolları daha ayrıntılı olarak sonra ele alacağız, ancak şimdilik yolun secret ön ekine sahip olması önemlidir, aksi takdirde bu örnek çalışmayacaktır. secret/ öneki, gizli verilermizin okunup yazılabileceği yeri gösterir.
İsterseniz çoklu veri parçaları halinde yazabilirsiniz:
$ vault write secret/hello value=world excited=yes
Success! Data written to: secret/hellovault write çok güçlü bir komutur. Komut satırından doğrudan veri yazmanın yanı sıra, değerler ve anahtar çiftlerini STDIN'den ve dosyalardan okuyabilir. Daha fazla bilgi edinmek için, vault write belgelerine bakın.
Uyarı: Belgeler,
anahtar=değertemelli girdiyi kullanır, ancak mümkünse dosyaları kullanmak daha güvenlidir. CLI yoluyla veri göndermek genellikle terminal geçmişine kaydedilir. Gerçekten gizli bilgilerinizin güvenliği için dosyaları kullanın. Daha fazla bilgi için STDIN'den okumaya ilişkin yukarıdaki bağlantıya bakın.
Tahmin edebileceğiniz gibi gizli veriler vault read komutu ile okunabilir:
$ vault read secret/hello
Key Value
--- -----
refresh_interval 768h0m0s
excited yes
value worldGördüğünüz gibi, yazdığımız değerler bize geri veriliyor. Vault veriyi depodan okuyor ve bizim için çözümlüyor.
Çıktı biçimi, awk gibi bir araç ile Tabular olarak düzenlenmiş.
Tabular çıktı biçime ek olarak, eğer jq gibi bir araçla çalışıyorsanız, verileri JSON formatında çıktı alabilirsiniz:
$ vault read -format=json secret/hello
{
"request_id": "68315073-6658-e3ff-2da7-67939fb91bbd",
"lease_id": "",
"lease_duration": 2764800,
"renewable": false,
"data": {
"excited": "yes",
"value": "world"
},
"warnings": null
}Bu format, bazı ek bilgiler içermektedir. Birçok gizli veri yönetim servisi (backend), Gizli bilgiler için zamanaşımıyla diğer sistemlerin erişimini kısıtlayan sağlayan kullanım süresini destekler. Bu durumlarda lease_id bir kullanım süresi içerecek ve lease_duration saniye bazında kullanımının geçerli olduğu süreyi içerecektir.
Verilerimizin burada detaylı bir dökümünü görüyoruz. JSON çıktısı komut dosyaları için çok yararlıdır. Örneğin aşağıdaki örnekte excited Gizli verisinin değerini elde etmek için jq aracını kullanıyoruz:
$ vault read -format=json secret/hello | jq -r .data.excited
yesArtık gizli bir veriyi okuma ve yazmayı öğrendiğimize göre, silme işlemine geçebiliriz. Bunu vault delete ile yapabiliriz:
$ vault delete secret/hello
Success! Deleted 'secret/hello' if it existed.Daha önce, gizli verileri Valut'a nasıl yazacağımızı ve okuyacağımızı gördük. Bunu yapmak için, secret/ önekini kullandık. Bu önek hangi gizli veri yönetim servisinin kullanılacağını belirtir. Varsayılan olarak Vault, generic adlı bir gizli veri yönetim servisini secret'a bağlar. generic gizli veri yönetim servisi, ham veriyi disk üzerinden okur ve yazar.
Vault generic gizli veri yönetim servisine ek olarak farklı gizli veri yönetim servislerini de desteklemektedir ve bu özellik Vault'u benzersiz kılan özelliktir. Örneğin, AWS gizli veri yönetim servisi, isteğe bağlı olarak AWS erişim anahtarlarını dinamik olarak üretir. Başka bir örnek - bu tür bir gizli veri yönetim servisi henüz mevcut değil - doğrudan bir HSM'ye veri yazar ve okur. Vault olgunlaştıkça giderek daha fazla gizli veri yönetim servisi eklenecektir.
Vault Gizli Veri Yönetim Servislerini Dosya Sistemine Çok Benzer Şekilde Kullanır:
Depolama birimleri belirli yollar (path) yardımı ile tanımlanır. Örneğin generic gizli veri yönetim servisi secret/ önekini alarak tanımlanır.
Bu sayfada, gizli veri yönetim servislerinin tanımlanmasını ve gizli veri yönetim servisleri ile gerçekleştirilebilecek işlemler hakkında bilgi edineceğiz. İlerleyen bölümlerde dinamik olarak gizli veri oluşturacağımız işlemlerde buradaki bilgilerden faydalanacağız.
İlk başta, başka bir generic gizli veri yönetim servisi elde edelim. Normal bir dosya sistemi gibi Vault da birden fazla gizli veri yönetim servisi tanımlanabilir. Farklı erişim denetimi ilkeleri veya farklı yollar için yapılandırmalar istiyorsanız bu özellik işinize yarayacaktır.
Gizli Veri Yönetim Servisi Tanımlama:
$ vault mount generic
Successfully mounted 'generic' at 'generic'!Varsayılan olarak, depomalama tanımı ile gizli veri yönetim servisi aynı isimde olacaktır. Bunun nedeni, zamanın %99'unu depolama tanımını özelleştirmek için harcamamamızdır. Bu örnekte, generic gizli veri yönetim servisini generic/ adresine kurduk.
Depolama Tanımlarını vault mounts ile inceleyebilirsiniz:
$ vault mounts
Path Type Description
generic/ generic
secret/ generic generic secret storage
sys/ system system endpoints used for control, policy and debuggingGörüldüğü gibi generic/ depolama tanımının yanı sıra secret/ ve sys/ yolunu da içermektedir. Bu konuya şimdilik değinmeyeceğiz. Bilgi vermek açısından sys/ bağlantı noktası Vault ile iletişime geçmek için kullanılır.
Herşeyin yolunda olduğundan emin olmak için bazı gizli verileri yeni gizli veri yönetim servisine yazın ve okuyun. İlk olarak secret/ erişim noktasına yazın ve generic/ yolu ile bu değerleri okuyamadığınızı göreceksiniz: Aynı depolama alanını paylaşmalarına rağmen, hiçbir gizli veriyi paylaşmıyorlar. Buna ek olarak, (aynı türden veya farklı türden) gizli veri yönetim servisleri de diğer gizli veri yönetim servislerinin verilerine erişemez; Yalnızca bağlama noktası/servis tanımı içindeki verilere erişebilirler.
Bir gizli veri yönetim servisi kaldırıldığında, bütün gizli veriler iptal edilir ve silinir. Bu işlemlerden herhangi biri başarısız olursa, gizli veri yönetim servisi kaldırma işlemi iptal edilir.
$ vault unmount generic/
Successfully unmounted 'generic/' if it was mountedBir gizli veri yönetim servisini kaldırdığınızda, tekrar eklemeniz mümkündür. Depolama birimini tekrar ekleme, depolama tanımının/bağlantı noktasını değiştirir. Bu operasyonda yıkıcıdır. Saklanan veriler korunsa da gizli veriler secret/ yoluyla bağlantılı olduğu için iptal edilmiştir.
Artık bir gizli veri yönetim servisini ekdiğinize ve çıkardığınıza göre: Gizli Veri Yönetim Servisi nedir ve bu gizli veri yönetim servisi tanımlama sisteminin anlamı nedir?
Vault sanal bir dosya sistemi gibi çalışır. Okuma, yazma ve silme işlemleri gizli veri yönetim servisine yönlendirilir ve gizli veri yönetim servisi bu işlemleri gerçekleştirir. Örneğin generic gizli veri yönetim servisi, basit bir şekilde verileri depolama alanına (Storage Backend) iletir. (şifreledikten sonra)
Bununla birlikte AWS Gizli Veri Yönetim Servisi (yakında göreceğiz), IAM ilkelerini okur, yazar ve erişim anahtarına erişebilir. Yani bu işlemleri vault read aws/deploy ile gerçekleştirken, okuma aws/deploy fiziksel yolu üzerinde gerçekleşmez. Buun yerine AWS Depolama birimi dağıtım ilkesine uygun bir erişim anahtarı üretir.
Bu soyutlama inanılmaz güçlüdür. Vault arayüzü fiziksel sistemler ile doğrudan bağlantı kurabilmenin yanı sıra SQL veritabanları, HSM'ler gibi sistemleride arayüze bağlar. Fakat bu fiziksel sistemlere ek olarak Vault, daha eşsiz ortamlarla etkileşim kurabilir: AWS IAM, dinamik SQL Kullanıcı yaratma vb hepsi aynı okuma/yazma arabirimini kullanmaktadır.
Vault'a gizli verilerimizi yazdık ve gizli veri yönetim servisi tanımlama gibi özelikleri anladık. Şimdi, Vault'un bir sonraki temel özelliği olan: Gizli veri üretme operesyonlarına geçeceğiz.
Gizli veri üretme yani dinamik gizli veriler, erişildikleri zaman üretilen gizli verilerdir ve İlk Gizli Veri bölümün deki gibi el yordamıyla yazılmamıştır. Bu sayfada AWS erişim anahtarlarını dinamik olarak oluşturmak için yerleşik AWS gizli veri yönetim servisini kullanacağız.
Dinamik Gizli Verinin gücü, sadece okunmadan önce var olmamalarıdır; bu nedenle, birinin bu gizli veriyi veya başka bir müşteri verisini çalma riski yoktur. Vault yerleşik iptal mekanizmalarına sahip olduğundan, dinamik gizli veri kullanımdan hemen sonra iptal edilebilir ve gizli verilerin var olduğu süreyi en aza indirebilir.
Not: Bu sayfayı başlatmadan önce, lütfen bir AWS hesabı için kayıt olunuz. Maliyete neden olan hiçbir özelliği kullanmayacağız, bu nedenle herhangi bir şey için ücret ödememelisiniz. Bununla birlikte, doğabilecek herhangi bir masrafdan biz sorumlu değiliz.
İlk dinamik gizli verimizi üretelim. Dinamik olarak AWS erişim anahtarı çifti oluşturmak için AWS gizli veri yönetim servisini kullanacağız. İlk olarak, AWS gizli veri yönetim servisini tanımlayın:
$ vault mount aws
Successfully mounted 'aws' at 'aws'!AWS gizli veri yönetim servisi aws/ adresine monte edildi. Bir önceki bölümde değindiğimiz gibi, farklı gizli veri yönetim servisleri farklı davranışlar sergiler ve bu örnekte AWS gizli veri yönetim servisi, AWS erişim kimlik bilgilerini oluşturmak için dinamik bir arayüz oluşturur.
AWS gizli veri yönetim servisi tanımlandığında, ilk adım, onu diğer kimlik bilgilerini oluşturmak için kullanılacak AWS kimlik bilgileri ile yapılandırmaktır. Şimdilik, AWS hesabınız için root anahtarlarını kullanın.
Depolama birimini yapılandırmak için, vault write komutunu aws/config/root yolu üzerinde kullanacağız:
$ vault write aws/config/root \
access_key=AKIAI4SGLQPBX6CSENIQ \
secret_key=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
Success! Data written to: aws/config/rootDinamik veri gizli veri yönetim servislerinin sadece okurken/yazarken veriyi oluşturduğunu unutmayın, tanımlı olan bu yoldaki yapılandırmayı saklayacaktır ancak daha sonra okunamıyacaktır:
$ vault read aws/config/root
Error reading aws/config/root: Error making API request.
URL: GET http://127.0.0.1:8200/v1/aws/config/root
Code: 405. Errors:
* unsupported operationKimlik bilgilerini güvenli tutmaya yardımcı olmak için AWS gizli veri yönetim servisi, kimlik bilgilerini root yetkisi kullansanız bile onları okumanıza izin vermez.
Bir sonraki adım AWS gizli veri yönetim servisini IAM ilkesiyle yapılandırmaktır. IAM, sınırlı API izinlerine sahip yeni kimlik bilgileri oluşturmak için AWS'nin kullandığı sistemdir.
AWS gizli veri yönetim servisi, oluşturulan kimlik bilgilerini ilişkilendirmek için IAM ilkesini gerektirir. Bu örnek için yalnızca bir politika yazacağız, ancak birçok politikayı arka uç ile ilişkilendirebilirsiniz. Aşağıdaki içeriğe sahip policy.json adlı bir dosya oluşturun:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1426528957000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
]
}
]
}Bu, kullanıcının Amazon EC2 içinde herhangi bir işlem yapmasını sağlayan temel bir IAM politikasıdır. Kaydelien ilkeyi, Vault'a tanıtım ve yeni bir rol oluşturun:
$ vault write aws/roles/deploy policy=@policy.json
Success! Data written to: aws/roles/deployVault'a bir IAM ilkesi yazmak için aws/roles/<ADI> gibi özel bir yol kullanıyoruz. Ayrıca, bir dosyanın içeriğini değer olarak yazmak için vault write komutunda özel bir parametre olarak @filename i kullandık.
AWS gizli veri yönetim servisini yapılandırdık ve bir rol oluşturduk, şimdi bu rol için bir erişim anahtarı çifti talep edebiliyoruz. Bunu yapmak için, aws/creds/<ADI> özel yolunu okuyun, burada ADI rolün adıdır:
$ vault read aws/creds/deploy
Key Value
--- -----
lease_id aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5
lease_duration 768h0m0s
lease_renewable true
access_key AKIAJFN42DVCQWDHQYHQ
secret_key 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
security_token <nil>Harika! Artık access_key ve secret_key AWS içerisinde herhangi bir EC2 işlemini gerçekleştirmek için kullanılabilir. İsterseniz, çalıştığını doğrulayabilirsiniz. Ayrıca, bu anahtarların yeni olduğunu, daha önce girdiğiniz anahtarlar olmadığını farketmişsinizdir.
Yukarıdaki lease_id, yenileme, iptal etme vb. operasyonlar için Vault tarafından kullanılan özel bir kimliktir. Şimdi Lease ID'nizi kopyalayın ve kaydedin.
Döngüyü tamamlayalım ve bu gizli veriyi şimdi iptal edelim, ve tamamen yok edelim. Gizli veri iptal edildikten sonra, erişim anahatarları artık çalışmayacaktır.
Gizli veriyi iptal etmek için, vault revoke çalıştırdığınızda okuduğunuz vault tan elde ettiğiniz dan çıkan LEASE ID yi kullanın :
$ vault revoke aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5
Success! Revoked the secret with ID 'aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5', if it existed.Tamadır! AWS hesabınıza bakarsanız, hiçbir IAM kullanıcısı olmadığını farkedeceksiniz. Üretilen erişim anahtarlarını kullanmaya çalışırsanız, artık çalışmadığını göreceksiniz.
Dinamik gizli veri oluşturma ve iptal etme araçları yardımı ile dinamik gizli verilerle çalışmanın ne kadar kolay olduğunu görmeye başladık. Bu verilerin yalnızca ihtiyaç duydukları süre boyunca varolmalarını garantileyebiliyoruz.
Şu ana kadar vault write ve vault read okuma/yazma pratikleri üzerine çalıştık: secret/ yolu ile generic gizli veri yönetim servisini ve aws/ yolu ile AWS gizli veri yönetim servisi üzerinden dinamik AWS kimlik bilgileri oluşturduk. Her iki durumda da, her gizli veri yönetim servisinin yapısı ve kullanımı farklılıklar gösterdi; örneğin AWS gizli veri yönetim servisi, aws/config gibi özel yollara sahip olduğunu gördük.
Hangi yolları kullanacağınızı belirlemek için sürekli ezberlemek veya belgelere referans vermek zorunda kalmadan, doğrudan Vault ile çalışan bir yardım sistemi kurduk. Bu yardım sistemine API veya komut satırı üzerinden erişilebilir ve tanımlanmış herhangi bir gizli veri yönetim servisi için okunaklı bir yardım üretir.
Bu sayfada, bu yardım sistemini nasıl kullanacağınızı öğreneceğiz. Vault'u kullanırken çok değerli bir araçtır.
Bunun için AWS gizli veri yönetim servisinin takılı olduğunu varsayacağız. Değilse, vault mount aws ile bağlayın. Bir AWS hesabınız olmasa bile yine de AWS gizli veri yönetim servisine bağlayabilirsiniz.
Depolama birimi tanımlıyken thevault path-help komutunu deneyelim:
$ vault path-help aws
## DESCRIPTION
The AWS backend dynamically generates AWS access keys for a set of
IAM policies. The AWS access keys have a configurable lease set and
are automatically revoked at the end of the lease.
After mounting this backend, credentials to generate IAM keys must
be configured with the "root" path and policies must be written using
the "roles/" endpoints before any access keys can be generated.
## PATHS
The following paths are supported by this backend. To view help for
any of the paths below, use the help command with any route matching
the path pattern. Note that depending on the policy of your auth token,
you may or may not be able to access certain paths.
^config/lease$
Configure the default lease information for generated credentials.
^config/root$
Configure the root credentials that are used to manage IAM.
^creds/(?P<name>\w+)$
Generate an access key pair for a specific role.
^roles/(?P<name>\w+)$
Read and write IAM policies that access keys can be made for.vault path-help komutu olası yolları listeler. Bir gizli veri yönetim servisi için temel adresini belirterek, bu gizli veri yönetim servisinin genel özelliklerini bize listeler. Yardımın sadece bir açıklama içerdiğini değil, aynı zamanda bu gizli veri yönetim servisi için güzergâhları eşleştirmek için kullanılan tam düzenli ifadelerin, güzergahın neyle ilgili olduğunu da söylemektedir.
Genel bilgiyi aldıktan sonra, tek tek bir yol için yardım alarak daha derinlere dalmaya devam edebiliriz. Bunun için, vault path-help komutunu bilgi edinmek istediğiniz ifadeyle eşleşen bir yolla birlikte kullanın. Yolun aslında çalışması gerekmediğini unutmayın.
$ vault path-help aws/creds/operator
Request: creds/operator
Matching Route: ^creds/(?P<name>\w+)$
Generate an access key pair for a specific role.
## PARAMETERS
name (string)
Name of the role
## DESCRIPTION
This path will generate a new, never before used key pair for
accessing AWS. The IAM policy used to back this key pair will be
the "name" parameter. For example, if this backend is mounted at "aws",
then "aws/creds/deploy" would generate access keys for the "deploy" role.
The access keys will have a lease associated with them. The access keys
can be revoked by using the lease ID.Bir yol içinde, bu yolun gerektirdiği parametreleri içerir. Bazı parametreler adresin kendisinden gelmektedir. Bu durumda, name parametresi rota düzenli ifadesinin adlandırılmış bir eşleniğidir.
Bu yolun ne yaptığının bir açıklaması da var.
Daha fazla yol keşfedebilirsiniz! Diğer gizli veri yönetim servislerini kurun, yardım sistemlerini dolaşın ve yaptıklarını öğrenin. Örneğin, thesecret/ yolu ile generic gizli veri yönetim servisi hakkında bilgi edinin.
Artık Vault'un temellerini ve nasıl kullanacağımızı bildiğimizden Vault'un kendisinin kimliğinin nasıl doğrulanacağını anlamak önemlidir. Bu noktaya kadar kimlik doğrulaması yapmamız gerekmiyordu çünkü geliştirici modunda Vault sunucusunun başlatılması bizi otomatik olarak root kullanıcısı olarak kaydediyordu. Gerçek kullanımda, neredeyse her zaman el yordamı ile kimliğinizi doğrulamanız gerekir.
Bu sayfada, kimlik doğrulama hakkında özel olarak konuşacağız. Bir sonraki sayfada yetkilendirme hakkında konuşacağız. Kimlik doğrulama, Vault kullanıcısına bir kimlik tahsis etme mekanizmasıdır. Bir kimlikle ilişkili erişim kontrolü, izinleri ve yetkileri bu sayfada ele alınmayacaktır.
Vault, kurulabilir kimlik doğrulama sistemlerine sahiptir ve kuruluşunuz için en iyi sistemi kullanarak Vault ile kimlik doğrulamasının etkisi artırlır. Bu sayfada, token backend'in yanı sıra GitHub sistemlerini kullanacağız.
Diğer kimlik doğrulama sistemlerini gözden geçirmeden önce token kimlik doğrulamasını inceleyeceğiz. Token kimlik doğrulaması Vault'da varsayılan olarak etkindir ve devre dışı bırakılamaz.
Vault geliştirici sunucusu -dev ile başlattığında, Vault root tokenı oluşturur. root token Vault'u yapılandırmak için ilk erişim anahtarıdır. root ayrıcalıklarına sahiptir, bu nedenle Vault içindeki herhangi bir işlemi gerçekleştirebilir. Bir sonraki bölümde ayrıcalıkları nasıl sınırlayacağımızı ele alacağız.
vault token-create komutunu kullanarak daha fazla token yaratabilirsiniz:
$ vault token-create
Key Value
token c2c2fbd5-2893-b385-6fa5-30050439f698
token_accessor 0c1c3317-3d58-17e5-c1a9-3f54fa26610e
token_duration 0
token_renewable true
token_policies [root]Varsayılan olarak, bu mevcut tüm erişim denetimi ilkelerini devralan geçerli erişim anahtarının alt üyesini oluşturur. Buradaki "alt üye" konsepti önemlidir: Tokenların her zaman bir ebeveyni vardır ve ebeveyn işaretçisi iptal edildiğinde, alt üyeler de tek seferde tümüyle iptal edilebilir. Bu, bir kullanıcının erişimi kaldırırken, kullanıcının oluşturduğu tüm alt tokenlar için erişimi kaldırmasını kolaylaştırır.
Bir token yaratıldıktan sonra, vault token-revoke ile iptal edebilirsiniz:
$ vault token-revoke c2c2fbd5-2893-b385-6fa5-30050439f698
Success! Token revoked if it existed.Bir önceki bölümde,vault revoke komutunu kullandık. Bu komut yalnızca gizli verileri iptal etmek için kullanılır. Token ları iptal etmek için vault token-revoke komutu kullanılmalıdır.
Bir token ile kimlik doğrulaması yapmak için vault auth komutunu kullanın:
$ vault auth d08e2bd5-ffb0-440d-6486-b8f650ec8c0c
Successfully authenticated! The policies that are associated
with this token are listed below:
rootBu komut Vault kimliğini doğrular. Kimliğinizi doğrular ve token ile ilişkili erişim politikalarını size bildirir. Vault yetkilisini test etmek isterseniz, önce yeni bir token oluşturduğunuzdan emin olun.
Token kimlik doğrulama sistemine ek olarak, başka kimlik doğrulama veya yetkili sistemleri etkinleştirilebilir. Vault ile tanımlanan Kimilik Doğrulama Sistemleri ile bazı alternatif yöntemlere sahip oluruz. Bu kimlikler, Token kimlik doğrulama sistemi gibi bir dizi erişim politikasına bağlıdır. Örneğin masaüstü ortamları için özel anahtar veya GitHub tabanlı kimlik doğrulama kullanılabilir. Sunucu ortamları için, paylaşılan gizli veriler en iyisi seçenek olabilir. Kimilik Doğrulama Sistemleri, bize farklı kimlik doğrulama yöntemleri arasında seçme esnekliği sağlar.
Örnek olarak, GitHub'ı kullanarak kimlik doğrulamasını yapalım. Önce, GitHub Kimilik Doğrulama Sistemini etkinleştirin:
$ vault auth-enable github
Successfully enabled 'github' at 'github'!Kimilik Doğrulama Sistemleri, gizli veri gizli veri yönetim servisleri gibi tanıtılır; temel fark, Kimilik Doğrulama Sistemleri her zaman auth/ öneki alır. Bu yüzden, daha önce kurduğumuz GitHub Kimilik Doğrulama Sistemine auth/github adresinden erişilebilir. Bunun hakkında daha fazla bilgi edinmek için vault path-help yardımını kullanabilirsiniz.
GitHub Kimilik Doğrulama Sistemi etkinleştirildiğinde, öncelikle yapılandırmamız gerekir. GitHub için, kullanıcıların hangi organizasyonun parçası olması gerektiğini ve ekibin hangi politikayla eşleştiğini söylemeliyiz:
$ vault write auth/github/config organization=hashicorp
Success! Data written to: auth/github/config
$ vault write auth/github/map/teams/default value=default
Success! Data written to: auth/github/map/teams/defaultYukarıdaki bölüm, GitHub Kimilik Doğrulama Sistemizin yalnızca hashicorp kuruluşundaki kullanıcıları kabul etmek için (kendi organizasyonunu doldurmalısın) ve ekibi yerleşik bir politika olan varsayılan politikaya eşleştirmek için yapılandırdı.Şu anda bir sonraki bölüme geçebiliriz.
GitHub etkinleştirildiğine göre, artık vault auth kullanarak kimlik doğrulaması yapabiliriz:
$ vault auth -method=github token=e6919b17dd654f2b64e67b6369d61cddc0bcc7d5
Successfully authenticated! The policies that are associated
with this token are listed below:
defaultİşte Oldu! GitHub'ı kullanarak kimlik doğrulamasını yaptık. Varsayılan ilke (default), benim kimliğiyle ilişkiliydi. Erişim Anahtarı (token) kişisel Erişim Anahtarı olmalıdır.
Farkettiyseniz, komutları çalıştırmak için daha önce var olan root erişim anahtarı ile yeniden kimlik doğrulaması yapıldı.
Herhangi bir Kimilik Doğrulama Sisteminin, kimlik doğrulamasını vault token-revoke komutunu kullanarak iptal edebilirsiniz; Bu işlem önek kullanılarak yapılır. Örneğin, tüm GitHub belirteçlerini iptal etmek için aşağıdakileri çalıştırabilirsiniz:
$ vault token-revoke -mode=path auth/githubİşiniz bittiğinde, Kimilik Doğrulama Sistemini vault auth-disable ile devre dışı bırakabilirsiniz. Kimilik Doğrulama Sistemi üzerinde doğrulanmış tüm kullanıcıları geçersiz kılacaktır.
$ vault auth-disable github
Disabled auth provider at path 'github'!"Vault" daki erişim kontrol politikaları, bir kullanıcının erişim haklarını kontrol eder. Son bölümde kimlik doğrulamayı öğrendik. Bu bölüm yetkilendirme ile ilgilidir.
Vault Kimlik doğrulama için etkinleştirilebilen ve kullanılabilen birden çok seçenek veya sistem içerir. Yetki ve erişim kontrolü politikaları için Vault daima aynı biçimi kullanır. Tüm kimlik doğrulama sistemleri, kimlikleri "theVault" ile yapılandırılan temel politikaları ile eşleştirmelidir.
Vault'u başlatıldığında, kaldırılamayan , önceden oluşturulmuş özel bir politikaya sahiptir: root erişim politikası. Bu politika Vault'taki her şeye süper kullanıcı erişimi sağlayan özel bir politikadır. root politikasıyla eşlenen bir kimlik ile her şeyi yapabilirsiniz.
Vault'daki politikalar HCL ile biçimlendirilir. HCL, JSON ile uyumlu, kolay okunabilen bir yapılandırma biçimidir, bu nedenle de JSON'u da kullanabilirsiniz. Örnek bir politika aşağıda gösterilmektedir:
path "secret/*" {
policy = "write"
}
path "secret/foo" {
policy = "read"
}
path "auth/token/lookup-self" {
policy = "read"
}Politika formatı, erişim denetimini belirlemek için API adresinde bir önek eşleştirme sistemi kullanır. Kesin tanımlanmış politika, tam eşleşme veya en uzun ön ek eşlemesi olabilir. Vault'daki herşeye API aracılığıyla erişilmesi gerektiğinden, Vault'un bütün özellikleri üzerinde, gizli veri yönetim servislerinin montajı, kimlik doğrulaması ve gizli bilgilere erişimi de dahil olmak üzere tüm yönleriyle sıkı bir denetim sağlar.
Yukarıdaki politikaya sahip bir kullanıcı, secret/ yoluna herhangi bir gizli veri yazabilir, ancak sadece salt okunur secret/foo verisini okuma erişimine sahiptir. Politikalar varsayılan olarak red eğilimdedir; dolayısıyla belirtilmemiş bir yola erişim mümkün değildir. Politika söz dizimi Vault 0.2 versiyonunda biraz değişti, ayrıntılar için bu sayfaya bakın.
Yukarıdaki Politikayı acl.hcl adlı bir dosyaya kaydedin.
Bir politika yazmak için vault policy-write komutunu kullanın:
$ vault policy-write secret acl.hcl
Policy 'secret' written.vault policies ile kullanılabilen politikaları listeleyebilir ve vault policies <name> ile varolan bir politikanın içeriğini görebilirsiniz. Yalnızca root erişime sahip kullanıcılar bunu yapabilir.
Politikayı kullanmak için, bir token oluşturup bu politikaya atayalım. Daha sonra bir root kullanıcıya kimlik doğrulaması yapabilmeniz için root erişim anahtarınızı başka bir yere kaydedin.
$ vault token-create -policy="secret"
Key Value
token d97ef000-48cf-45d9-1907-3ea6ce298a29
token_accessor 71770cc5-14da-f0af-c6ce-17a0ae398d67
token_duration 2764800
token_renewable true
token_policies [default secret]
$ vault auth d97ef000-48cf-45d9-1907-3ea6ce298a29
Successfully authenticated!
token: d97ef000-48cf-45d9-1907-3ea6ce298a29
token_duration: 2591938
token_policies: [default, secret]Artık, secret/ için veri yazabildiğinizi test edebilirsiniz, tabi yalnızca thesecret/foo adresinden okuyabilirsiniz:
$ vault write secret/bar value=yes
Success! Data written to: secret/bar
$ vault write secret/foo value=yes
Error writing data to secret/foo: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/secret/foo
Code: 403. Errors:
* permission deniedAynı zamanda politikaya göre sys'e erişiminiz yok, bu nedenle vault mounts gibi komutlar da kullanılamaz.
Vault tekil politika sistemine sahiptir. Çoklu kimlik doğrulama sistemleri bağlayabileceğiniz kimlik doğrulamadan farklıdır. Monte edilmiş herhangi bir kimlik doğrulama sistem kimliği bu temel ilkelerle eşlemelidir.
Her kimlik doğrulama sistemi kendine özgü olduğundan haritalamanın nasıl yapıldığını belirlemek için vault path-help ile yardım bölümnden destek alırız. Örneğin, GitHub ta, map/teams/<team> adresini kullanarak takıma eşleştirme yaparız:
$ vault write auth/github/map/teams/default value=secret
Success! Data written to: auth/github/map/teams/defaultGitHub için varsayılan ekip, hangi takımdan olursa olsun herkesin atandığı varsayılan politikayı kullanır.
Diğer kimlik doğrulama sistemleri, politikaları kimlikle eşlemek için alternatif oluşturur, ancak benzer şekilde çalışır.
Bu noktaya kadar otomatik olarak kimlik doğrulaması yapan, bellek içi depolamayı kuran geliştirici sunucu ile çalıştık. Şimdi Vault'un temellerini bildiğinize göre, Vault'u gerçek ortamda nasıl yapılandırılacağını öğrenmek önemlidir.
Bu sayfada, Vault'u nasıl yapılandıracağınızı, nasıl başlatacağımızı, seal/unseal işlemini ve Vault'u nasıl ölçekleyeceğimizi ele alacağız.
Vault HCL dosyaları kullanılarak yapılandırılmıştır. Bir hatırlatma olarak, JSON dosyaları da tamamen HCL uyumludur; HCL, JSON'un üst kümesidir. Vault'un konfigürasyon dosyası nispeten basittir. Aşağıda bir örnek gösterilmiştir:
backend "consul" {
address = "127.0.0.1:8500"
path = "vault"
}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = 1
}Bu yapılandırma dosyasında iki temel yapılandırma vardır:
backend - Vault'un depolama için kullandığı fiziksel gizli veri yönetim servisi. Bu noktaya kadar geliştirici sunucusu "bellekiçi" (bellekte) kullandı, ancak yukarıdaki örnekte gerçek ortam için çok daha uygun bir gizli veri yönetim servisi olan Consul kullanıyoruz.
listener - Vault'un API isteklerini dinlemek için bir veya daha fazla dinleyici belirler. Yukarıdaki örnekte, TLS olmadan localhost 8200 numaralı bağlantı noktasını dinliyoruz. Ortam değilkeninizi VAULT_ADDR=http://127.0.0.1:8200 olarak ayarlayın, böylece Vault istemcisi TLS olmadan bağlanır.
Şimdilik, yukarıdaki yapılandırmayı kopyalayıp example.hcl adlı bir dosyaya yapıştırın. Vault Consul'un yerel makinada çalıştığını varsayarak yapılandırılacaktır.
Yerel ortamda Consul'u başlatmak yalnızca birkaç dakika alır. Bu örnekte Consul ile çalışabilmek için Consul Başlangıç Kılavuzunu takip etmeniz ve şu komutu kullanarak başlatmanız yeterlidir:
$ consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -bind 127.0.0.1Konfigürasyon şartlarının yerine getirilmesiyle, sunucunun başlatılması aşağıda gösterildiği gibi basittir. -config parametresini yukarıdaki yapılandırmayı kaydettiğiniz doğru yolu gösterecek şekilde değiştirin.
$ vault server -config=example.hcl
==> Vault server configuration:
Log Level: info
Backend: consul
Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
==> Vault server started! Log data will stream in below:Vault, konfigürasyonu hakkında bazı bilgiler verir ve sonra bloklar. Bu işlem, systemd veya upstart gibi bir kaynak yöneticisi kullanılarak çalıştırılmalıdır.
Hiçbir komut yürütemediğinizi fark edeceksiniz. Herhangi bir yetkilendirme bilgimiz yok! İlk olarak Vault sunucusunu kurduğunuzda, sunucuyu önyükleme ayarları ile birlikte başlatmanız gerekir.
Linux'ta Vault aşağıdaki hatayla başlamayabilir:
$ vault server -config=example.hcl
Error initializing core: Failed to lock memory: cannot allocate memory
This usually means that the mlock syscall is not available.
Vault uses mlock to prevent memory from being swapped to
disk. This requires root privileges as well as a machine
that supports mlock. Please enable mlock on your system or
disable Vault from using it. To disable Vault from using it,
set the `disable_mlock` configuration option in your configuration
file.Bu konuyla ilgili daha detaylı yönergeler için, Sunucu Yapılandırması'ndaki disable_mlock tartışmasına bakın.
Önyükleme,Vault'u ilk yapılandırma işlemidir. Bu, Vault tarafından daha önce kullanılmayan yeni bir gizli veri yönetim servisi ile başlatıldığında bir kez olur.
Önyükleme sırasında şifreleme anahtarları ve mühür açıcı (unseal) anahtarlar oluşturulur ve ilk root erişim anahtarı (token) üretilir. Vault'u başlatmak için vault init komutunu kullanın. Bu kimliği doğrulanmamış bir istektir, ancak yalnızca herhangi bir veri içermeyen yepyeni Vault üzerinde çalışır:
$ vault init
Key 1: 427cd2c310be3b84fe69372e683a790e01
Key 2: 0e2b8f3555b42a232f7ace6fe0e68eaf02
Key 3: 37837e5559b322d0585a6e411614695403
Key 4: 8dd72fd7d1af254de5f82d1270fd87ab04
Key 5: b47fdeb7dda82dbe92d88d3c860f605005
Initial Root Token: eaf5cc32-b48f-7785-5c94-90b5ce300e9b
Vault initialized with 5 keys and a key threshold of 3!
...Önyükleme, inanılmaz derecede önemli iki bilgiyi bize verir: mühür açıcılar (unseals) ve ilk root erişim anahtarı. Bu an, verilerin Vault tarafından bilinen tek anı ve mühürleri gördüğümüz tek zamandır.
Bu başlangıç kılavuzu amacına yönelik olarak, tüm bu anahtarları bir yere kaydedin ve devam edin. Gerçek bir dağıtım senaryosunda, bu anahtarları birlikte asla kaydetmezsiniz. Bunun yerine, muhtemelen Vault'un PGP ve keybase.io desteğini kullanarak bu anahtarların her birini kullanıcıların PGP anahtarlarıyla şifrelemektesiniz. Bu, tek bir kişinin tüm mühür açıcıları almasını önler. Daha fazla bilgi için PGP, GPG ve Keybase'yi kullanma ile ilgili dokümanlara bakın.
Bütün Vault sunucuları mühürlü (sealed) durumda başlar. Vault yapılandırmadan fiziksel depolama alanına erişebilir ancak herhangi bir dosyayı okuyamaz, çünkü şifrenizi nasıl çözeceğini bilmemektedir. Verilerin şifresinin nasıl çözüleceğini Vault'a öğretme işlemine, "mühür açmak" (unsealing) olarak adlandırılır.
Vault her başladığında mühür açıcı olmalı. Bu API aracılığıyla ve komut satırı aracılığıyla yapılabilir. Vault'u mühürlemek için, mühür açıcı anahtarlarının eşik sayısına sahip olmalısınız. Yukarıdaki çıktıda, "anahtar eşiğinin" 3 olduğuna dikkat edin. Bu, Vault'un kapanması için üretilen 5 anahtarın 3'üne ihtiyacınız olduğu anlamına gelir.
Not: Vault, açılmamış anahtar parçalarından hiçbirini saklamaz. Vault, ana anahtarın kırıklara bölünmesi için Shamir's Secret Sharing olarak bilinen bir algoritma kullanıyor. Sadece anahtar eşik sayısı ile yeniden yapılandırabilir ve verilerinize böylece erişebilirsiniz.
Mühür Açma işlemine "vault unseal" ile başlayın:
$ vault unseal
Key (will be hidden):
Sealed: true
Key Shares: 5
Key Threshold: 3
Unseal Progress: 1Geçerli bir anahtarı doğruladıktan sonra, Vault'un hala mühürlü olduğunu görürsünüz, ancak ilerleme kaydedilir. Vault, 3 anahtarın 1 olduğunu bilir. Algoritmanın niteliğinden dolayı, Vault, eşiğe ulaşılıncaya dek doğru anahtara sahip olup olmadığınızı bilmiyor.
Ayrıca işe yaramayan işlemlerin durum bilgisinin tutulduğuna dikkat edin. Başka bir bilgisayara gidebilir, vault unseal komutunu kullanabilirsiniz ve aynı sunucuya işaret ettiği sürece diğer bilgisayar açılış işlemine devam edebilir. Bu, işe yaramayan işlemin tasarımı için inanılmaz derecede önemlidir: Vault'un kapanması için birden çok anahtara sahip birden çok kişiye ihtiyaç vardır. Vault birden fazla bilgisayardan mühürlenebilir ve anahtarlar birlikte olmamalıdır. Tek bir kötü niyetli operatörün kötü amaçlı olması için yeterli sayıda anahtars sahip olmamalıdır.
Vault'un mühürünü açmak için vault unseal işlemine devam edin. Vault'u açmak için üç farklı tuş kullanmanız gerekir; aynı tuş tekrarlanmaz. Anahtarları doğru kullandıkça, yakında şu şekilde çıktığını görmelisin:
$ vault unseal
Key (will be hidden):
Sealed: false
Key Shares: 5
Key Threshold: 3
Unseal Progress: 0Sealed:false Vault'un mühürlü olduğu anlamına gelir!
The Sealed:false : Vault'un mühürlü olduğu anlamına gelir!
Mühür açma işlemini anlamak için geçersiz anahtarınların kullanılması gibi farklı denemeler yapmaktan çekinmeyin. Devam etmeye hazır olduğunuzda, root token ile kimliğinizi doğrulamak için vault auth komutunu kullanın.
root yetkilerinde bir kullanıcı ile olarak vault seal komutu yardımı ile Vault'u tekrar mühürleyebilirsiniz. root yetkilerine sahip Tek bir operatöre bu izin verilir. Bu, tek bir operatörün, acil bir durumda, Vault'un diğer operatörlere danışmadan kilitlemesini sağlar.
Vault tekrar mühürlendiğinde, mevcut durum bilgisi (şifreleme anahtarı da dahil olmak üzere) bellekten temizlenir. Vault güvene alınmış ve erişimden kapatılmıştır.
Vault'un tüm yeteneklerine CLI'ye ek olarak HTTP API aracılığıyla da erişilebilir. Aslında, CLI'den gelen çoğu çağrı HTTP API'yi çağırır. Bazı durumlarda, Vault'un özelliklerine CLI üzerinden erişmek mümkün değildir ve yalnızca HTTP API üzerinden erişilebilir.
Vault sunucusunu başlattıktan sonra, API çağrıları yapmak için curl veya başka bir http istemcisini kullanabilirsiniz. Örneğin, Vault sunucusunu geliştirme modunda başlattıysanız, başlatma durumunu şu şekilde doğrulayabilirsiniz:
$ curl http://127.0.0.1:8200/v1/sys/initBu istek bir JSON yanıtı döndürür:
{ "initialized": true }Vault'da saklanan bilgilere erişmek isteyen makineler, muhtemelen Vault aygıtına REST API'sini kullanarak erişebilirler. Örneğin, bir makine kimlik doğrulama için AppRole kullanıyorsa, uygulama ilk olarak Vault için kimlik doğrulaması yapıp Vault API erişim anahtarı döndürür. Uygulama, bu anahtarı Vault ile gelecekte iletişim kurarken kullanacaktır.
Bu kılavuzun amacı doğrultusunda, TLS'yi devre dışı bırakan, dosya tabanlı gizli veri yönetim servisi kullanan aşağıdaki yapılandırmayı kullanacağız. TLS burada yalnızca örnek amaçlı olarak devre dışı bırakılmıştır ve gerçek ortamda hiçbir zaman devre dışı bırakılmamalıdır.
backend "file" {
path = "vault"
}
listener "tcp" {
tls_disable = 1
}Bu dosyayı diske kaydedin ve vault sunucusunu şu komutu kullanarak çalıştırın:
$ vault server -config=/etc/vault.confBu noktada, tüm etkileşimlerimiz için vault API'yı kullanabiliriz. Örneğin, Vault'u şöyle başlatabiliriz:
$ curl \
-X PUT \
-d "{\"secret_shares\":1, \"secret_threshold\":1}" \
http://127.0.0.1:8200/v1/sys/initYanıt aşağıdaki JSON çıktısına benziyor olmalı:
{
"root_token": "4f66bdfa-f5e4-209f-096c-6e01d863c145",
"keys_base64": [
"FwwsSzMysLgYAvJFrs+q5UfLMKIxC+dDFbP6YzyjzvQ="
],
"keys": [
"170c2c4b3332b0b81802f245aecfaae547cb30a2310be74315b3fa633ca3cef4"
]
}Bu yanıt root erişim anahtarımızı içeriyor. Ayrıca mühür açma anahtarı da yanıtla birlikte gelir. Vaultu açmak için mühür açma anahtarı kullanabilir ve root erişim anahtarını kullanarak Vault'da kimlik doğrulaması gerektiren diğer işlemleri gerçekleştirebilirsiniz.
Bu kılavuzda anlatılan operasyonları rahatlıkla uygulamanız ve root erişim anahtarını depolamak için $VAULT_TOKEN çevre değişkeni kullanacağız. Vault erişim anahtarını terminalde şu şekilde dışa aktarabilirsiniz:
$ export VAULT_TOKEN=4f66bdfa-f5e4-209f-096c-6e01d863c145Mühür açma anahtarını (root erişim anahtarını içermez) kullanarak yukarıdan Vault'u HTTP API aracılığı açabilirsiniz:
$ curl \
-X PUT \
-d '{"key": "FwwsSzMysLgYAvJFrs+q5UfLMKIxC+dDFbP6YzyjzvQ="}' \
http://127.0.0.1:8200/v1/sys/unsealFwwsSzM ... 'yi sizin elde ettiğiniz anahtarla değiştirmeniz gerektiğini unutmayın. Bu komut JSON yanıtı döndürür:
{
"cluster_id": "1c2523c9-adc2-7f3a-399f-7032da2b9faf",
"cluster_name": "vault-cluster-9ac82317",
"version": "0.6.2",
"progress": 0,
"n": 1,
"t": 1,
"sealed": false
}Artık kimlik doğrulama sistemlerinden herhangi birini etkinleştirilebilir ve yapılandırılabilirsiniz. Bu kılavuzun amacı doğrultusunda AppRole kimlik doğrulamasını etkinleştireceğiz.
AppRole kimlik doğrulamasını etkinleştirin:
$ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" -d '{"type":"approle"}' http://127.0.0.1:8200/v1/sys/auth/approleAppRole etkinleştirmek için yapılan istekte bir kimlik doğrulama erişim anahtarı gerektiğine dikkat edin. Bu örnekte Vault sunucusunu başlattığımızda oluşturulan root erişim anahtarını geçiyoruz. Ayrıca, diğer kimlik doğrulama mekanizmalarını kullanarak başka erişim anahtarı üretebiliriz, ancak şimdilik basitlik için root erişim anahtarını kullandık.
Şimdi, istenen ACL politikaları kümesine sahip bir istektete bulunun. Aşağıdaki komutta, AppRole testrole rolününe verilen erişim anahtarının dev-policy ve test-policy ile ilişkilendirilmesi gerektiği belirtilmektedir.
$ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" -d '{"policies":"dev-policy,test-policy"}' http://127.0.0.1:8200/v1/auth/approle/role/testroleVarsayılan yapılandırmasında AppRole kimlik doğrulama sistemi, role_id ve secret_id adıyla iki adet kimlik bilgisine ihtiyaç duyar. Bu komut, testrole rol kimliğini (role_id) alır.
$ curl -X GET -H "X-Vault-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/auth/approle/role/testrole/role-id | jq .{
"auth": null,
"warnings": null,
"wrap_info": null,
"data": {
"role_id": "988a9dfd-ea69-4a53-6cb6-9d6b86474bba"
},
"lease_duration": 0,
"renewable": false,
"lease_id": "",
"request_id": "ef5c9b3f-e15e-0527-5457-79b4ecfe7b60"
}Bu komut, testrole'un altında yeni bir secret ID oluşturur.
$ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/auth/approle/role/testrole/secret-id | jq .{
"auth": null,
"warnings": null,
"wrap_info": null,
"data": {
"secret_id_accessor": "45946873-1d96-a9d4-678c-9229f74386a5",
"secret_id": "37b74931-c4cd-d49a-9246-ccc62d682a25"
},
"lease_duration": 0,
"renewable": false,
"lease_id": "",
"request_id": "c98fa1c2-7565-fd45-d9de-0b43c307f2aa"
}Bu iki kimlik bilgisi, yeni bir Vault erişim anahtarı elde etmek için oturum açma adresi (auth/approle/login) üzerinde kullanılır.
$ curl -X POST \
-d '{"role_id":"988a9dfd-ea69-4a53-6cb6-9d6b86474bba","secret_id":"37b74931-c4cd-d49a-9246-ccc62d682a25"}' \
http://127.0.0.1:8200/v1/auth/approle/login | jq .{
"auth": {
"renewable": true,
"lease_duration": 2764800,
"metadata": {},
"policies": [
"default",
"dev-policy",
"test-policy"
],
"accessor": "5d7fb475-07cb-4060-c2de-1ca3fcbf0c56",
"client_token": "98a4c7ab-b1fe-361b-ba0b-e307aacfd587"
},
"warnings": null,
"wrap_info": null,
"data": null,
"lease_duration": 0,
"renewable": false,
"lease_id": "",
"request_id": "988fb8db-ce3b-0167-0ac7-1a568b902d75"
}Döndürülen istemci erişim anahtarı (client token) (98a4c7ab-b1fe-361b-ba0b-e307aacfd587) artık Vault ile kimlik doğrulaması yapmak için kullanılabilir. Bu erişim anahtarı, varsayılan, dev-policy ve test-policy politikaları tarafından kapsanan tüm kaynaklar üzerinde belirli operasyonları gerçekleştirebilir.
Yeni edinilen erişim anahtarı yeni bir VAULT_TOKEN olarak dışa aktarılabilir ve Vault isteklerinin kimliğini doğrulamak için bu değişken kullanabilir.
$ export VAULT_TOKEN="98a4c7ab-b1fe-361b-ba0b-e307aacfd587"
$ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" -d '{"bar":"baz"}' http://127.0.0.1:8200/v1/secret/fooBu verilen JSON içeriğiyle "foo" adlı yeni bir gizli veri oluşturacaktır. Bu değeri aynı erşiim anahtarı ile okuyabiliriz:
$ curl -X GET -H "X-"thesVassult"-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/secret/foo | jq .Aşağıdaki gibi bir JSON yanıtı dönecektir:
{
"auth": null,
"warnings": null,
"wrap_info": null,
"data": {
"bar": "baz"
},
"lease_duration": 2764800,
"renewable": false,
"lease_id": "",
"request_id": "5e246671-ec05-6fc8-9f93-4fe4512f34ab"
}Diğer kullanılabilir API talep adresleri ile ilgili daha fazla ayrıntı bilgi için HTTP API' belgelerini inceleyebilirsiniz.
Tebrikler! Artık Vault ile çalışmak için gereken tüm temel bilgilere sahipsiniz.
Vault için başlangıç kılavuzunun sonuna geildik. Umarım Vault'un yetenekleri seni heyecanlandırmıştır ve buradaki bilgiler süreçlerini iyileştirmek için yeterlidir.
Bu kılavuzda Vault'un tüm özelliklerinin temellerini anlattık. Gizli bilgilerin güvence altına alınmasının öneminden dolayı, aşağıdaki yönergeleri okumanızı öneririz.
Dokümantasyon - Dokümantasyon,Vault'un tüm özelliklerine ilişkin ayrıntılı bir referans kaynağıdır.
Vault kurulumu oldukça basittir. Vault kurulumunda iki yaklaşım vardır:
Hazır derlenmiş bir dosyayı indirmek en kolayıdır ve dosyayı TLS üzerinden SHA256 doğrulaması ile indiririz. Doğrulanabilen SHA256 ile birlikte PGP imzası da dağıtıyoruz.
Önceden derlenmiş bir dosyayı yüklemek için, sisteminiz için uygun paketi indirin. Vault bir zip dosyası olarak paketlenmiştir. Farklı türde sistem paketleri sağlamak için kısa vadeli bir planımız yok.
Zip indirildikten sonra, herhangi bir dizine unzip edin. vault dosyası (Windows için vault.exe), Vault'u çalıştırmak için gerekli olan tek şeydir. Diğer dosyalar Vault'u çalıştırmak için gerekli değildir.
Dosyayı sisteminizdeki herhangi bir yere kopyalayın. Komut satırından erişmeyi düşünüyorsanız, PATH ortam değişkenine, bulunduğu dizini eklediğinizden emin olun.
Kaynaklardan derlemek için Git'in yüklü olması ve düzgün bir yapılandırmaya sahip olmanız gerekir. (bir GOPATH ortam değişkeni seti de dahil olmak üzere).
- Vault deposunu GitHub'dan GOPATH'a kopyalayın:
$ mkdir -p $GOPATH/src/github.com/hashicorp && cd $!
$ git clone https://github.com/hashicorp/vault.git
$ cd vault- Projeyi önyükleyin. Bu operasyon, Vault dosyasını derlemek için gerekli kütüphaneleri ve araçları indirecek ardından derleyecektir:
$ make bootstrap- Geçerli sisteminiz için Vault dosyasını oluşturun ve dosyayı
./bin/dizinine yerleştirin.make devyerel ortamınız içinvault'u oluşturan bir kısayoldur (çapraz derleme yapmaz).
$ make devVault yazılımının doğru şekilde kurulduğunu doğrulamak için sisteminizde vault -v komutunu çalıştırın. Yardım çıktısını görmelisiniz. Komut satırından çalıştırıyorsanız, Vault'un bulunduğu adresin PATH'te tanımlı olduğundan emin olun. Aksi taktirde hata alabilirsiniz.
$ vault -vBu bölüm Vault'u daha derinlemesine ele alır ve Vault'un işlevlerinin, mimarisinin ve güvenlik özelliklerinin teknik ayrıntılarını açıklar.
Not: Vault'u ile ilgili derinlemesine bilgi edinmek, Vault'u kullanabilmek için gerekli değildir. Vault'un işleyişi hakkında derinlemesine bilgi almak istemiyorsanız bu bölümü güvenle atlayabilirsiniz. Vault'u hali hazırda kullanan deneyimli bir kullanıcıysanız, buradaki detaylı bilgilerden faydalanmanızı öneririz.
Vault çok farklı parçalara sahip karmaşık bir sistemdir. Bu sayfada , hem kullanıcıların hem de geliştiricilerin Vault'un nasıl çalıştığına ilişkin zihinsel bir model oluşturmasına yardımcı olmak amacıyla sistem mimarisini anlatacağız.
Zor Bir Konu! Bu sayfa Vault'un teknik ayrıntılarını kapsar. Vault'u etkin bir şekilde kullanmak için bu ayrıntıları anlamanıza gerek yoktur. Detaylar, kaynak kodu üzerinden inceleme yaparak öğrenmek zorunda kalmadan, arkada neler döndüğünü öğrenmek isteyenler için anlatılmıştır. Bununla birlikte, Vault operatörü iseniz, Vault'un öneminden dolayı mimari hakkında bilgi edinmenizi öneririz.
Mimariyi tanımlamadan önce, tartışılanları netleştirmek için terimler sözlüğü faydalı olacaktır:
-
Depolama Birimi (Storage Backend) - Depolama birimi, şifreli verilerin kalıcı olarak depolanmasından sorumludur. Yaklaşım olarak Vault, Depolama Birimlerine güvenilmez ve yalnızca hizmet devamlılığı beklenir. Depolama birimleri Vault sunucusu başlatılırken yapılandırılır.
-
Bariyer (Barrier) - Bariyer, Vault etrafındaki kriptografik çelik zırhtır. Vault ve Depolama Birimi arasında akan tüm veriler bariyerin içinden geçer. Bariyer, yalnızca şifrelenmiş verilerin yazılmasını sağlar ve veri bu yolla doğrulanır ve çözülür. Vault bir banka gibi, içerideki herhangi birşeye erişmeden bariyer "mühürlenmiş" (unsealed) olmalıdır.
-
Gizli Veri Yönetim Servisi (Secret Backend) - Gizli veri yönetim servisi, gizli verilerin yönetiminden sorumludur.
genericgizli veri yönetim servisi gibi basit gizli veri servisleri, sorulduğunda aynı veriyi döndürür. Bazı servisler, sorgulanırlarken her zaman bir Gizli Veri üreten politikaları kullanmayı destekler. Bu, Vault'un kendine has gizli veriler için gelişmiş iptal operasyonları ve politika güncellemeleri yapmasına olanak sağlar. Örnek olarak, bir MySQL hizmeti bir "web" politikasıyla yapılandırılabilir. "Web" politikası üzerinden çalıştığınızda, web sunucusu için sınırlı bir ayrıcalık grubu ile yeni bir MySQL kullanıcı/şifre çifti oluşturulabilirsiniz. -
Denetim Servisi (Audit Backend) - Bir denetim servisi denetim günlüklerini yönetmekten sorumludur. Vault'a yapılan her talep ve Vault'dan gelen yanıt, yapılandırılmış denetim servisleri üzerinden geçer. Bu, Vault'u farklı türden birden çok denetim günlüğü ile entegre etmek için basit bir yol sağlar.
-
Kimlik Doğrulama Servisi (Credential Backend) - Vault'a bağlanan kullanıcıların veya uygulamaların kimlik doğrulamasında Kimlik Doğrulama Servisi kullanılır. Kimlik doğrulaması yapıldıktan sonra servis, uygulanabilir politikaların listesini döndürür. Vault, kimliği doğrulanmış bir kullanıcıyı alır ve gelecekteki istekler için kullanılabilecek bir istemci erişim anahtarı (client token) döndürür. Örnek olarak,
user-passwordservisi, kullanıcının kimliğini doğrulamak için bir kullanıcı adı ve parola kullanır. Alternatif olarak,githubkimlik doğrulama servisi, kullanıcıların GitHub ile kimlik doğrulamasını sağlar. -
İstemci Erişim Anahtarı (client token) - Bir istemci erişim anahtarı, kavramsal olarak bir web sitesindendeki oturum çerezine benzemektedir. Bir kullanıcı kimliği doğruladıktan sonra, Vault gelecekteki istekler için kullanılan bir istemci erişim anahtarı döndürür. Anahtar, Vault tarafından istemcinin kimliğini doğrulamak ve uygulanabilir ACL (Erişim kontrol politikası) ilkelerini uygulamak için kullanılır. Bu anahtar, HTTP üstbilgileri yoluyla iletilir.
-
Gizli Veri (secret) - Gizli veri, Vault tarafından geri gönderilen, gizli veya kriptografik materyal içeren bir terimdir. Vault tarafından döndürülen her şey bir gizli veri değildir. Örneğin sistem yapılandırması, durum bilgisi veya servis ilkeleri gizli veri olarak kabul edilmez. Gizli verilerin her zaman kendileri ile ilişkili bir kullanım süresi içerir. Bu, müşterilerin Gizli Verinin içeriğinin süresiz olarak kullanamayacağı anlamına gelir. Vault, süre bitiminde gizli veriyi iptal eder veya bir operatör, süre bitmeden önce Gizi Veriyi iptal etmek için müdahale edebilir. Anahtarlar ve politikalar üzerinde elle müdahale olmaksızın değişikliklere izin verdiği için Vault ve müşterileri arasındaki bu sözleşme önemlidir.
-
Sunucu - Vault, sunucu tabanlı bir mimariye sahiptir. Vault sunucusu, müşterilerine; tüm servisler arasındaki etkileşimi, ACL ve gizli veri yönetemi gibi operasyonaları yürütmeye olanak veren bir API sağlar. Sunucu tabanlı bir mimariye sahip olmak müşterileri güvenlik anahtarları ve politikalarından koparır, merkezi denetim günlüğü sağlar ve operatörler için yönetimi kolaylaştırır.
Vault hakkında yüksek düzeyde bir genel bakış şöyle görünür:
Hadi, Bu resimi parçamaya başlayalım. Güvenlik bariyerinin içinde veya dışında bulunan bileşenler birbirinden net bir şekilde ayrılır. Sadece depolama birimi ve HTTP API dışında, tüm diğer bileşenler bariyerin içindedir.
Depolama birimine güvenilmez, bu yüzden sadece şifreli verileri saklamaya elverişlidir. Vault sunucusu başlatıldığında, herhangi bir yeniden başlatma operasyonunda verilerin tekrar erişilebilir olması için depolama birimini kullanılır. Benzer şekilde, HTTP API'si başlangıçta Vault sunucusu tarafından başlatılmalıdır, böylece müşteriler istemci ile etkileşimde bulunabilir.
Vault ilk başladığına mühürlenmiş (sealed) durumdadır. Vault üzerinde herhangi bir işlem yapılmadan önce mühür açılmalıdır. Bu, mühür açma anahtarlarını kullanılarak yapılır. Vault başlatıldığında, tüm verileri korumak için kullanılan bir şifreleme anahtarı üretir. Bu anahtar bir ana anahtar tarafından korunmaktadır. Varsayılan olarak, Vault, ana anahtarın 5 parçaya bölünmesi için Shamir's secret sharing algorithm olarak bilinen bir teknik kullanır; bu 5 parçadan 3'ü ana anahtarın yeniden yapılandırılması için gereklidir.
Parça sayısı ve minimum eşik değeri kullanıcı tarafından belirtilebilir. Shamir'in tekniği devre dışı bırakılabilir ve ana anahtar, mühür açma için doğrudan kullanılır. Vault şifreleme anahtarını alır almaz, depolama birimindeki verilerin şifresini çözebilir ve mühürlüsüz duruma geçer. Mühürsüz durumda, Vault, yapılandırılmış tüm denetim, kimlik bilgisi ve gizli veri yönetim servislerini yükler.
Bu hizmetlerin konfigürasyonu, güvenlik açısından hassas olduklarından Valut'da saklanmalıdır. Yalnızca doğru izinlere sahip kullanıcılar bunları değiştirebilmelidir, yani bariyerin dışında tanımlanamazlar. Onları Vault'da depolamak, ACL'deki tüm değişikliklerin ACL sistemi tarafından korunmasını ve denetim günlükleri tarafından izlenebilmesini sağlar.
Vault'un mührünün açılmasından sonra, talepler HTTP API üzerinden Sisteme gönderilebilir. Sistem, isteklerin akışını yönetmek, ACL'leri uygulamak ve denetim günlüğünün yapılmasını sağlamak için kullanılır.
Bir müşteri ilk önce Vaulta bağlandığında, kimlik doğrulaması yapması gerekir. Vault , kullanılan kimlik doğrulama mekanizmasında esneklik sağlayan kimlik bilgisi servislerini kullanır. username/password veya GitHub gibi insancıl mekanizmalar operatörler için kullanılabilirken, uygulamalarda kimliği doğrulamak için public/private anahtarları veya erişim anahtarları kullanabilir. Bir kimlik doğrulama isteği, sistem aracılığıyla, isteğin geçerli olup olmadığını belirleyen ilişkili poliçelerin listesini kimlik doğrulama servisine aktarır.
Politikalar sadece adlandırılmış bir ACL kuralıdır. Örneğin, "root" politikası yerleşik olarak bulunur ve tüm kaynaklara erişime izin verir. Sistem üzerinde gelişmiş denetime sahip istediğiniz sayıda politika oluşturabilirsiniz. Vault sadece beyaz liste modunda çalışıyor, yani bir politika yoluyla erişim açıkça verilmediği sürece bu işleme izin verilmiyor. Bir kullanıcının ilişkili birden çok politikası olabileceğinden, herhangi bir politika ona izin veriyorsa bir işleme izin verilir. Politikalar, bir iç politika deposu tarafından saklanır ve yönetilir. Bu dahili birim, her zaman sys/ adresine tekabül eden sistem hizmetleriyle yürütülür.
Kimlik doğrulaması gerçekleştiğinde ve Kimlik Doğrulama Servisi uygulanabilir bir dizi politika sağladığında, yeni bir müşteri erişim anahtarı, erişim anahtarı birimi tarafından oluşturulur ve yönetilir. Bu istemci erişim anahtarı, müşteriye geri gönderilir ve gelecekte istekte bulunmak için kullanılır. Bu, bir kullanıcı oturum açtıktan sonra bir web sitesi tarafından gönderilen bir çereze benzer. İstemci erişim anahtarı, Kimlik Doğrulama Servisi yapılandırmasına bağlı olarak onunla ilişkilendirilmiş bir kullanım süresine sahip olabilir. Bu durum, erişimi geçersiz kılmayı önlemek için istemci erişim anahtarının periyodik olarak yenilenmesi gerekebileceği anlamına gelir.
Kimlik doğrulaması gerçekleştikten sonra istemci erişim anahtarı sağlayan istekler yapılır. Erişim anahtarı, müşterinin yetkili olduğunu doğrulamak ve ilgili politikaları yüklemek için kullanılır. İlkeler, istemci isteğini yetkilendirmek için kullanılır. Ardından, talep, servis türüne bağlı olarak işlenen Gizli Veri Yönetim Servislerine yönlendirilir. Servis bir gizli veri döndürürse, sistem onu son kullanma yöneticisine kaydeder ve bir kira kimliği (lease_id) ekler. Kira kimliği, müşterileri tarafından gizli veriyi yenilemek veya iptal etmek için kullanır. Bir müşteri kira kimliğinin geçerliliğini yitirmesine izin verirse, Vault gizli veriyi otomatik olarak iptal eder.
Sistem, taleplerin günlüğe kaydedilmesini ve denetçinin verdiği yanıtları değerlendirir ve yapılandırılmış denetim servislerine yönlendirir. İstek akışı dışında, sistem belirli görevleri gerçekleştirir. Kiralama yönetimi kritik önem taşır çünkü zaman aşımına uğramış müşteri erişim anahtarıları ya da gizli verilerin otomatik olarak iptal edilmesine olanak sağlar. Buna ek olarak, Vault kısmi hata durumlarını, geri alma (rollback manager) yöneticisi ile günlüğe işler (kayıt altına alır). Bu günlük sistem içinde şeffaf bir şekilde yönetilir ve günlük kullanıcı tarafından görüntülenemez.
Az önce Vault mimarisine kısa bir genel bakış yaptık. Sistemlerin her biri için daha ayrıntılı konuşabiliriz.
Diğer ayrıntılar için, kaynak kodu inceleyebilir, IRC'ye sorabilir veya posta listesine ulaşabilirsiniz.
Vault öncelikli olarak, gizli verilerin yönetilmesi için yayında olan hizmetlerimizde kullanılır. Sonuç olarak, Vault hizmetinin herhangi bir kesintisi, müşterilere sunulan hizmet kalitesini etkileyebilir. Vault, bir makinenin veya bir işlemin başarısızlığının minimum düzeyde etki yaratmasını sağlamak amacıyla yüksek kullanılabilirliğe sahip bir dağıtım mekanizması üzerine tasarlanmıştır.
Zor Bir Konu! Bu sayfa Vault'un teknik ayrıntılarını kapsar. Vault'u etkin bir şekilde kullanmak için bu ayrıntıları anlamanıza gerek yoktur. Detaylar, kaynak kodu üzerinden inceleme yaparak öğrenmek zorunda kalmadan, arkada neler döndüğünü öğrenmek isteyenler için anlatılmıştır. Bununla birlikte, Vault operatörü iseniz, Vault'un öneminden dolayı mimari hakkında bilgi edinmenizi öneririz.
Vault'u yüksek kullanılabilirliğe (HA) dönüştürme konusundaki temel tasarım hedefi, yatay ölçeklenebilirlik değil, aksama süresini en aza indirmektir. Vault genellikle hesaplama gereksinimlerinden ziyade depolama servislerinin Girdi/Çıktı sınırlarıyla sınırlandırılır. Bu, HA yaklaşımını kolaylaştırır ve daha karmaşık koordinasyonun önüne geçilmesini sağlar.
Consul gibi bazı depolama servisleri, Vault'un bir HA konfigürasyonunda çalışmasına olanak tanıyan ek koordinasyon işlevleri sağlar. Bu servislser tarafından desteklendiğinde, Vault otomatik olarak ek yapılandırmaya ihtiyaç duymadan HA modunda çalışır.
Vault HA modunda çalışırken, sunucularının içinde bulunabilecekleri iki durum vardır: bekleme modu ve etkin mod. Tek bir depolama birimi paylaşan birden çok Vault sunucusu, diğer makinalar bekleme modundayken, herhangi bir anda yalnızca bir tek makina ektin modda olur.
Etkin sunucu standart bir şekilde çalışır ve tüm istekleri karşilar. Bekleme modundaki sunucular istekleri işlemezler, bunun yerine etkin Vault sunucusuna yönlendirirler. Bu arada, etkin sunucu mühürlenirse, istek başarısız olur veya ağ bağlantısı kaybolursa, bekleme modunda olanlardan biri devralır ve etkin haline gelir.
Mührü açılmış olan sunucuların bekleme modu olarak hareket ettiklerini belirtmek önemlidir. Bir sunucu hala mühürlü durumdaysa, etkin sunucu başarısız olursa herhangi bir istekte bulunamayacağı için bekleme durumana geçemeyecektir.
Vault özelliğinden ve yönettiği verilerin gizliliğinden dolayı, Vault güvenlik modeli çok kritiktir. Vault'un güvenlik modelinin genel amacı, gizlilik, bütünlük, kullanılabilirlik, hesap verebilirlik ve kimlik doğrulama sağlamaktır.
Saklanan veriler, saklanmadan önce güvenli olmalıdır. Müşteriler, verilere erişmek veya erişim haklarını değiştirmek için uygun şekilde kimliği doğrulanmış ve yetkilendirilmiş olmalıdır. Tüm etkileşimler denetlenebilir olmalı ve orijinal varlığa benzersiz şekilde izlenmelidir. Sistem, erişim kontrollerinden herhangi birini atlamak için kasıtlı girişimlere karşı sağlam olmalıdır.