Vault 101
» Vault bizim Trendyol bünyesinde Secret Management konusunda kullandığımız ve öğrenmeye gayret ettiğimiz bir araç.Bu yazımda da yine Hashicorp’un bize başlangıç seviyesinde kendi geliştirdikleri araçları öğrenebilmemizi kolaylaştıran Learn Tutorial ‘ larından Vault’ un türkçeleştirdiğim versiyonunu paylaşmak istedim.
Kısaca Vault Nedir?
Secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
» Vault 2015 senesinde Mitchell Hashimoto’nun bir blog yazısıyla bize duyurduğu en basit haliyle bizim Secret Management konusundaki tüm ihtiyaçlarımız, problemlerimiz için çözüm sunan bir araç.Bu ihtiyaçlarımızın neler olduğuna değinmeden önce biz yazılım dünyasında Secret diyerek aslında neyi kast ediyor olabiliriz bundan bahsedelim.
Nedir bu Secret ?
» Aslında Secret , güvenliğinin önemli olduğu , başkaları tarafından görüntülenmesi veya bilinmesi sakıncalı olan , erişimin sınırlandırılması gereken ve mutlaka erişimlerin audit edilmesi gereken bilgiler olarak düşünebiliriz ayrıca buradaki “başkaları” kelimesine uygulamalarımız da dahil olacağını belirtelim.Peki biz bunlara neler örnek verebiliriz ? Database şifreleri, API Token, TLS Certificates , SSH Private keys , Cloud-Provider özgü Secret Keys .
» Mesela yukarıdaki görselde de Armon Dadgar’ ın bir sunumu sırasında Secret’in ne olduğu ile ilgili yaptığı bir açıklama.Yani bu açıklamaya bakarak da aslında bize yazılım dünyasında nelere Secret diyebileceğimiz bazı örnekler vererek anlatıyor.
» Peki şimdi ihtiyaçlarımıza gelelim , aslında Secret’ ın açıklamasını yaparken bu konudaki bir kaç ihtiyacımızdan da bahsetmiş olduk.
- Secret’larımı nasıl güvenli bir şekilde tutarım ?
- Secret’larımın erişimini nasıl sınırlandırabilirim ?
- Secret’larıma olan erişimleri nasıl audit edebilirim ?
- Uygulamalarım bu Secret’lara nasıl erişebilir ?
- Kişiler bu Secret’lara nasıl erişebilir ?
» Şimdi bu yazımızda tüm bu ihtiyaç ve problemlerimizi Vault’un nasıl çözdüğünden bahsedeceğiz.
Installing Vault
» Vault’un kurulumu da oldukça basit. Ben bu yazıda Mac kullandığım için OS X işletim sistemi üzerine nasıl kurabileceğimizden bahsedeceğim fakat linklediğim sayfada diğer işlem sistemleri için de nasıl kurubileceğimizden bahsediyor.
$ brew install vault » Vault'u yüklüyoruz$ vault » Vault binary'sinin doğru şekilde yüklenip yüklenmediğini test ediyoruz.
Usage: vault <command> [args]
Common commands:
read Read data and retrieves secrets
write Write data, configuration
...Ayrıca bu noktada benim için çok önemli olan "Command Completion"' Vault yapısal(built-in) olarak kendi komut seti içerisine eklemiş.Aşağıdaki komut sayesinde otomatik olarak ilgili yardımcı araçları gerekli terminal profilleri için yükler bu sayede vault yazıp ardından TAB'a bastığınızda komutların sizin için otomatik önerdiğini görebilirsiniz.
$ vault -autocomplete-install
Starting the Server
» Vault client/server uygulaması olarak hizmet verir.Vault Server, Vault’un mimarisindeki veri deposu(data storage) ve backend ile etkileşime geçen tek parçasıdır.Tüm işlemler Vault CLI’ın TLS bağlantısı üzerinde server ile iletişime geçerek gerçekleştirilir.
» İlk olarak Vault dev server’i başlatacağız, yani aslında buna dev mode da diyebiliriz.Dev server aslında önceden yapılandırılmış , Vault ile birlikte gelen , secure olmayan fakat Vault ile lokal ortamda kolayca çalışmamızı sağlayan bir server.Fakat daha detaylı açıklama istiyorsak eğer bununla ilgili çok güzel bir dökümantasyoları da mevcut.
$ vault server -dev==> Vault server configuration:Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Listener 1: tcp (addr: “127.0.0.1:8200”, cluster address: “127.0.0.1:8201”, max_request_duration: “1m30s”, max_request_size: “33554432”, tls: “disabled”)
Log Level: (not set)
Mlock: supported: false, enabled: false
Storage: inmem
Version: Vault v1.3.3
Version Sha: 37a1dc9c477c1c68c022d2084550f25bf20cac33WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.You may need to set the following environment variable:$ export VAULT_ADDR=’http://127.0.0.1:8200'The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0=
Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6xDevelopment mode should NOT be used in production installations!==> Vault server started! Log data will stream in below:# …
» Vault varsayılan olarak foreground process olarak başlatılır yani bu komutu çalıştırdıktan sonra diğer komut denemelerini yapabilmek için ayrı bir tab açmak gerekli fakat istersek tabi background process(vault server -dev > server.log 2>&1 &) olarak da başlatabiliriz.
Şimdi burada dev server ile ilgili bir kaç bilgi vermek gerekirse, dev server tüm verisini in-memory olarak saklar fakat encrypted, localhost üzerinde TLS olmadan dinler ve en önemli kısım aslında otomatik olarak initializing ve unsealing işlemlerini yapar dolayısıyla biz komutun çıktısında Unseal Key ve Root Access Key’i görebiliriz.Bu işlemler aslında çok fazlaca detay içeriyor dolayısıyla yine merak eden olursa bu linkten ve şu linkten detayını inceleyebilir.
NOT: Dev serverin production ortamda kullanılması önerilmiyor.
Şimdi dev serveri çalıştırdıktan sonra yapmamız gereken adımlardan bahsedelim.
- Yeni bir terminal sessionı açalım.
- Terminal çıktısında bize söylenen export VAULT_ADDR … komutunu kopyalayalım ve çalıştıralım , aslında bu şekilde Vault CLI ‘ ın lokalimizde kaldırdığımız dev server ile konuşacak şekilde yapılandırıyoruz.Yine bu değerlerin tüm listesine ulaşmak isterseniz işte link.
- Unseal Key’ i herhangi bir yerde -şuanda güvenliği çok da önemli değil- saklayalım.
- VAULT_DEV_ROOT_TOKEN_ID adında bir environment değişkenine komut çıktısındaki Root Token değerini verelim.
$ export VAULT_DEV_ROOT_TOKEN_ID=”s.XmpNPoi9sRhYtdKHaQhkHP6x”» Belirttiğimiz bu adımları gerçekleştirdikten sonra sıra Vault CLI’ın dev serveri ile konuştuğunu doğrulayacağız.
$ vault statusKey Value
---- ------
Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.3.3
Cluster Name vault-cluster-3cdf26fe
Cluster ID 08082f3a-b58d-1abf-a770-fbb8d87359ee
HA Enabled false
» Şimdi yukarıda bahsetmiş olduğum initializing ve unsealing işlemlerinin durumunu Initialized ve Sealed Key’lerinin değerleri ile kontrol edebiliriz.Bu değer dev serveri başlatıldığında yukarıdaki gibi Initialized true ve Sealed ise false olmalı aksi takdirde kurulum adımlarında bir hata yapmışız demektir.
Your First Secret
» Dev serverimizin Vault CLI’ı ile konuştuğunu teyit ettikten sonra ilk Secret’ımızı yazıp ardından okuyalım.(read/write).
» Vault’ un core(temel) özelliklerinden birisi de bu keyfi Secret’leri güvenli bir şekilde yazıp okuyabilme yeteneğidir. Biz genelde demolarımızda hep Vault CLI üzerinden işlemlerimizi gerçekleştireceğiz fakat Vault’ un bize sunduğu programatik olarak işlemler yapabilmemize imkan sağlayan HTTP API’si de mevcut.
» Vault’ a yazdığımız Secretlerimiz encrypt edildikten sonra Backend Storage’a yazılır.Aslında ileride daha detaylı bahsedeceğiz fakat Vault gerçekten her konuda çok esnek bir yapıya sahip burada bahsettiğimiz ve linkini paylaştığım Backend Storage tabiri de keza öyle yani siz Vault’ u kurduğunuzda Vault’ un desteklediği bir storage tipini tercih edebiliyorsunuz.Şimdi Dev server için yapılandırılan backend storage in-memory fakat production ortam için önerilen ise Consul veya bir disk.Vault Backend Storage’a Secret’in değerini yazmadan önce şifreler böylece Backend Storage bu değerin un-encrypted halini görmez ayrıca bu değeri decrypt edecek araçlara da sahip değildir.
» Şimdi ilk Secret’ımızı yazarak başlayalım, bunu yaparken Vault CLI’ın bize sağladığı vault kv komutundan faydalanacağız.Tüm komut listesine detaylı bakmak istersek diye linki paylaşıyorum.
$ vault kv put secret/hello foo=worldKey Value
— — — — -
created_time 2019–02–04T19:53:22.730733Z
deletion_time n/a
destroyed false
version 1
» Bu örneğimizde secret/hello path’ine foo keyinde world değerine sahip Secret’ı yazdık.Path kavramına daha sonraki bölümlerde değineceğiz fakat bu örnek için buradaki secret/ ön ekinin önemli olduğunu belirtelim çünkü örneğimiz aksi takdirde çalışmayacaktır.Aslında buradaki secret/ prefixi(ön ek) Vault için keyfi Secret’ların yazılıp okunduğu bir yer.
» İstersek tek komutta Secret’ın bir çok parçasını da yazabiliriz.
$ vault kv put secret/hello foo=world excited=yesKey Value
— — — — -
created_time 2019–02–04T19:54:03.250328Z
deletion_time n/a
destroyed false
version 2
» Buradaki örneğimizde datayı direk command-line üzerinden verdik fakat
vault kv put key/value değerlerini STDIN veya dosyadan da okuyabilme yeteneğine sahiptir.
» Secret’ı başarıyla yazdıktan sonra nasıl okuyabileceğimize bakalım.Buradaki kullancığımız komut ise vault kv get.
$ vault kv get secret/hello====== Metadata ======
Key Value
— — — — -
created_time 2019–02–04T19:54:03.250328Z
deletion_time n/a
destroyed false
version 2===== Data =====
Key Value
--- ---
excited yes
foo world
» Görüldüğü üzere yazdığımız değerler bize geri döndürüldü , Vault datayı Backend Storage’dan aldı ve onu decrypt etti.Komutun çıktısını biraz inceleyecek olursak bazı extra bilgilerin de olduğunu göreceğiz.Çoğu Secret Engine’ler bu Secret’lar için diğer sistemlere zaman-sınırlı erişim sağlayan leaseler (kiralamalar) oluşturur ve bu durumlarda lease_id lease’ in identifier(tanımlayıcı) değerini ve lease_duration da saniye cinsinden lease’ in valid(geçerli) olduğu süreyi içerir.
» Eğer istersek sadece ilgili key’in değerini yazdırabiliriz.
$ vault kv get -field=excited secret/helloyes
» Ayrıca -format flag’i ile beraber de çıktımızın formatını değiştirebiliriz bu da bazı scriptlerde JSON formatının gerekli olduğu durumlar için kullanılabilir.jq aslında JSON tabanlı veriler üzerinde operasyonlar yapmamızı kolaylaştıran bir tool bu örnekte excited key’inin değerini göstermek için kullanıyoruz.
$ vault kv get -format=json secret/hello | jq -r .data.data.excitedyes
» Gördük ki Secret yazmak ve okumak oldukça kolay şimdi nasıl bu Secret değerini silebileceğimize bakalım, bunun için de vault kv delete komutundan faydalanacağız.
$ vault kv delete secret/helloSuccess! Data deleted (if it existed) at: secret/hello
Secrets Engines
» Önceki örneklerimizde Secret’ı yazıp okurken hep secret/ prefixini kullandığımızı fark etmişsinizdir ve bunun önemli olduğunu aksi takdirde örneklerimizin çalışmayacağını söyledik şimdi bunu teyit edelim.Rastgele bir pathe Secret yazmayı deneyelim.
$ vault kv put foo/bar a=bError making API request.URL: GET http://localhost:8200/v1/sys/internal/ui/mounts/foo/bar
Code: 403. Errors:* preflight capability check returned 403, … grant access to path “foo/bar/”
» Gördüğünüz gibi hata aldık.Buradaki path prefix Vault’a hangi trafiğin hangi Secret Engine yönlendirilmesi gerektiğini bildirir. Vault’a bir istek geldfiğinde, en uzun prefix eşleşmesini kullanarak ilk path bölümü ile eşleşir ardından bu path de enable(aktifleştirilen) edilen Secret Engine’ e requesti iletir. Vault bu Secret Engine’leri bir dosya sistemine benzer şekilde sunar.
» Vault’u dev mode’ da başlattığımız bizim için otomatik olarak secret/ pathinde
Key/Value version2 Secret Engine’i enable edilir.Bu key/value Secret Engine, ham datayı(raw data) backend storage’ den okur ve yazar. Vault bir çok Secret Engine’ı destekler bu da Vault’u daha esnek ve benzersiz yapan özelliklerdendir.
» Az önce dedik ki Vault bir çok Secret Engine’i destekler, bu Secret Engine’leri kullanabilmeye başlamak için önce yapmamız gereken onları aktifleştirmektir.Şimdiki örneklerimizde kv Secret Engine’imizi aktifleştirip kullanacağız.Her path tamamiyle izoledir ve diğer bölümleriyle konuşamaz.Örneğin foo pathinde enable edilmiş bir kv Secret Engine bar pathinde enable edilmiş bir Secret Engine ile konuşamaz.
$ vault secrets enable -path=kv kvSuccess! Enabled the kv secrets engine at: kv/
» Yukarıdaki örneğimizde kv pathinde kv Secret Engine’i enable ettik.Aslında burada bir trick var o da şu eğer -path flag’ini vermeseydik path değeri default olarak enable edilen Secret Engine’in adı olacaktı yani yukarıdaki komutla aşağıdaki komut tamamen aynı işi yapar.
$ vault secrets enable kv» Secret Engine’ı enable edip edemediğimizi doğrulayalım.
$ vault secrets listPath. Type Accessor
— — ---- -------
cubbyhole/ cubbyhole cubbyhole_78189996
identity/ identity identity_ac07951e
kv/ kv kv_15087625
secret/ kv kv_4b990c45
sys/ system system_adff0898
» Bu komut çıktısı bize 4 adet enable edilmiş olan Secret Engine olduğunu söylüyor , aynı zamanda bunların tiplerini ve karşılık gelen pathlerini de görebiliyoruz.
NOT: sys/ pathi system backendine karşılık gelir, bu path Vault’un core sistemiyle etkileşim halindedir.
» Şimdi kv pathinde enable ettiğimiz kv Secret Engine’imize bazı Secretlar yazıp okuyalım.
$ vault kv put kv/hello target=world
Success! Data written to: kv/hello$ vault kv get kv/hello
===== Data =====
Key Value
--- -----
target world$ vault kv put kv/my-secret value="s3c(eT"
Success! Data written to: kv/my-secret$ vault kv get kv/my-secret
==== Data ====
Key Value
--- -----
value s3c(eT$ vault kv delete kv/my-secret
Success! Data deleted (if it existed) at: kv/my-secretŞimdi bu kv pathindeki tüm keyleri listeleyelim.$ vault kv list kv/
Keys
----
hello
» Secret Engine’e ihtiyacımız kalmadığı noktada onu disable edebiliriz.Bir Secret Engine disable edildiği durumda ilgili path içerisindeki tüm Secretlar revoke(iptal) edilir ve karşılık gelen data ve konfigürasyon silinir.
$ vault secrets disable kv/
Success! Disabled the secrets engine (if it existed) at: kv/burada dikkat edilmesi gereken bir şey var, bu komut Secret Engine'in path değerini argüman olarak alır tipini değil.
» Secret Engine’ler üzerinde bir çok işlem yaptık fakat gerçekte ne oldukları hakkında pek açıklama yapmadık.Şimdi gelin buna biraz ışık tutalım.
» Aslında yukarıda belirtmiştik Vault sanal bir dosya sistemi(virtual filesystem)gibi davranır.Tüm bu CRUD işlemleri karşılık gelen Secret Engine’e iletilir Secret Engine’da bu işlemlere karşı nasıl hizmet vermesi gerektiğine karar verir, buradaki soyutlama önemlidir çünkü bu soyutlama Vault’a fiziksel sistemlere, veritabanları vs ile bir arayüz oluşturmasını sağlar.
Dynamic Secrets
» Şimdi Vault’ un bir diğer core feature’ larından(özellik) olan Dynamic Secret konusunu keşfetme zamanı.Şimdiye kadar hep Secret Engine’lere datayı Vault CLI üzerinden biz pasladık bunun aksine Dynamic Secret’ler onlara erişildiklerinde oluştururlar.Yani Dynamic Secret’lar okunana kadar mevcut değildir dolayısıyla birinin onları çalma veya farklı bir clientın aynı Secretları okuma riski yoktur.Çünkü Vault built-in olarak revocation mekanizmasına sahip yani Secret varolma süresini minimize edebilmek için Dynamic Secret’lar okunduktan hemen sonra revoke(iptal) edilebilir.(buradaki iptal edilme süresini biz ayarlayabiliyoruz)
» Şimdi Dynamic Secret’leri de aslında bir Secret Engine tipi yani buradan şunu anlamakta fayda var her enable ettiğimiz Secret Engine’in davranış şekli farklı.Önceki örneğimizde Secret Engine’i nasıl enable edebileceğimizi görmüştük aynı şekilde Dynamic Secret’lerin nasıl çalıştığını örneklendirebilmek için AWS Secret Engine’i enable edip kullanacağız.
$ vault secrets enable -path=aws aws
Success! Enabled the aws secrets engine at: aws/» Yukarıda da dediğim gibi farklı Secret Engine’ler farklı davranışlara imkan tanır , burada da AWS Secret Engine talebe göre dinamik AWS access credentials(erişim kimlik bilgileri) üretir.Peki tüm bunları yaparken gerekli olan AWS’e erişim için kullanması gereken değerlere nereden sağlayacak, şimdi gelin buna bakalım.
» Dynamic Secret’lar enable edildikten sonra yapılandırmamız gerek yani bu örneği AWS Secret Engine üzerinden verirsek AWS’e iletişim kurabilmesi ve authenticate(kimliğini doğrulaması) için konfigüre(yapılandırma) etmemiz gerek ve bu değerler ayrıcalıklı bir hesabın credentiallarına ihtiyaç duyar.Yani ayrıcalıklı hesap aslında AWS Secret Engine’in dinamik olarak AWS Access Credentials oluşturabilmesi için gerekli olan yetkilere sahip bir hesap. Aslında bu noktada şunu merak ediyor olabilirsiniz , bu aws/config/root felan bu path’in AWS Secret Engine’i konfigüre etmek için kullanmamız gerektiğini nereden biliyoruz , merak etmeyin o konuya da geliyor olacağız :)
$ vault write aws/config/root \
access_key=AKIAI4SGLQPBX6CSENIQ \ secret_key=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 \
region=us-east-1
Success! Data written to: aws/config/root» Bir sonraki adım role’ün konfigüre edilmesi.Bu noktada Vault , AWS API sayesinde nasıl IAM(Identity and Access Management) user oluşturabileceğini biliyor fakat ona hangi izinlerin, grupların ve policylerin atanması istediğimizi bilmiyor işte bu noktada role’ler devreye giriyor, Vault’da role, aksiyonun(eylem) insan dostu bir tanımlayıcıdır.
» Örnek verecek olursak aşağıdaki bir IAM Policy’dir ve EC2 üzerindeki tüm aksiyonları gerçekleştirmeyi enable eder.
{
“Version”: “2012–10–17”,
“Statement”: [
{ “Sid”: “Stmt1426528957000”,
“Effect”: “Allow”,
“Action”: [“ec2:*”],
“Resource”: [“*”]
}
]
}» Bizim bu policy dökümanını adlandırılmış bir rol ile eşletirmemiz gerekiyor , bunu yapabilmek için aws/role/:name path’ine yazacağız. :name burada rolü belirtiyor.Ayrıca yine belirtmek istiyorum buradaki path’ler pre-defined yani belirli path’ler bunları nereden öğrendiğimizi dediğim gibi geleceğim o yüzden şimdilik bu noktalara takılmayalım , belirtmek istiyorum çünkü ben anlamaya çalışırken baya takılmıştım :)
$ vault write aws/roles/my-role \
credential_type=iam_user \
policy_document=-<<EOF
{
“Version”: “2012–10–17”,
“Statement”: [
{
“Sid”: “Stmt1426528957000”,
“Effect”: “Allow”,
“Action”: [
“ec2:*”
],
“Resource”: [
“*”
]
}
]
}
EOF
Success! Data written to: aws/roles/my-roleBiz az önce Vault’a şunu söyledik bu işlemi yaparak :
my-role için bir credential sorduğum zaman , oluştur ve ona bu IAM Policy’i ata.
» Bu noktaya kadar AWS Secret Engine’i enable edip konfigüre ettik şimdi bizim için dinamik bir Secret oluşturmasını isteyelim.Bunu yapabilmek için de yine önceden tanımlı olan bir path’i aws/creds/:name okumamız gerekecek bu sayede Vault’dan bizim için access key/pair oluşturmasını isteyeceğiz.Buradaki :name yerine varolan rolümüzün adı gelecek.
$ vault read aws/creds/my-role
Key Value
--- -----
lease_id aws/creds/my-role/0bce0782–32aa-25ec-f61d-c026ff22106e
lease_duration 768h
lease_renewable true
access_key AKIAJELUDIANQGRXCTZQ
secret_key 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
security_token <nil>» Komutun çıktısındaki access_key ve secret_key değerlerini istediğimiz EC2 işlemini gerçekleştirmek için kullanabiliriz.Eğer test etmek isterseniz AWS CLI’ı indirin ve ardından aws configure komutuyla beraber bu değerleri girin ve ardından aws ec2 describe-intances komutunu çalıştırın ve başarıyla EC2 instancelerini görüntülendiğini teyit edin.Buradaki değerlerin yeni olduğunu fark etmemiz gerek onları daha önceden biz girmedik.Eğer komutu ikince kez çalıştırsak yeni bir access key/pair elde ederiz yani her seferinde aws/creds/:name path’ den okuduğumuzda Vault AWS’e bağlanacak ve yeni bir IAM user’i ve key/pair oluşturacak.
» Buradaki çıktıda diğer Secret Engine’lerden farklı olarak bir lease_id oluşturulduğuna dikkat edelim bu lease_id ‘yi kopyalayalım çünkü daha sonra renewal(yenileme),revocation(iptal) ve inspection(gözlemleme) için kullanacağız.
» Vault’un built-in revocation mekanizmasını desteklediğini söylemiştik ve çıktıda da görüyoruz ki bunun default değeri 768 saat yani 768 saat sonra Vault bizim için bu Secret’ı revoke edecek fakat biz bu süreden daha önce bu revoke işlemini yapmak isteyebiliriz. Secret revoke edildiğinde, access keylerde artık mevcut olmayacak.
» Secret’ı revoke edebilmek için vault revoke komutuyla beraber lease_id’yi kullanacağız.
$ vault lease revoke aws/creds/my-role/0bce0782–32aa-25ec-f61d-c026ff22106
Success! Revoked lease: aws/creds/my-role/0bce0782–32aa-25ec-f61d-c026ff22106e» Yine bu işlemin ardından yukarıdaki işlemi tekrarlayın(aws komutlarını) ve bu sefer hata aldığınızı göreceksiniz.
Built-in Help
» İşte size bahsettiğim bu pre-defined path’leri nereden biliyoruz sorusunun cevabını vereceğimiz noktaya geldik, şimdi en basitinden bu path’leri öğrenmek için Secret Engine’ler sayfasına gidip oradaki dökümantasyonu okuyabiliriz fakat bu işlemi sürekli tekrarlamak yerine Vault built-in bir help sistemi var yine bu help sistemine Vault CLI üzerinden veya istenirse API üzerinden erişilebilir bu sistemin temel amacı herhangi bir path için insan dostu(human-friendly) bir yardım sayfası oluşturmaktır.
» Şimdi yukarıda anlattıklarımızı AWS Secret Engine ile örneklendirelim.
$ 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.
» İşte örneklerde kullandığımız pre-defined path’ ler burada ve işin güzel yanı bunların ne amaçla kullanabileceğimizi de bize söylüyor.Bu vault path-help komutu bir path değeri alır fakat root path’i verdiğimizde de bu örnekteki gibi bize Secret Engine için genel bir bakış sağlar.
» Ben ilk başta buradaki regular expressionların ne anlama geldiğini anlayamamıştım bir örnekle bu durumu açıklarsak daha iyi anlıyoruz.Aslında buradaki her bir bireysel path için de ayrı özel yardım sayfaları var bu regular expressionla eşleştirip o path için de yardım sayfasını görüntüleyebiliriz amaç bu yani ve şunu bilmekte fayda var bu vereceğimiz path’ in aslında çalışmasına ihtiyaç yok yani ne demek bu , gidip bu path’den bir değer okunabilir veya değer yazılabilir olmasına gerek yok , tek amaç regular expression ile eşleştirip o path’ in nasıl kullanıldığını öğrenmek.Mesela bu örnekte ^creds/(?P<name>\w+) için bir yardım sayfası elde edelim.
$ vault path-help aws/creds/my-non-existent-roleRequest: creds/my-non-existent-role
Matching Route: ^creds/(?P<name>\w(([\w-.]+)?\w)?)$Generate an access key pair for a specific role.### PARAMETERSname (string)
Name of the role### DESCRIPTIONThis 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.
Aslında bu kadar basit.
Authentication
» Şimdi geldik Vault’un en baba konularından birine :) Bu noktada Vault’a nasıl authenticate olabildiğimizi anlamak önemli.Bu noktaya kadar Vault’a hiç login(giriş) olmadık, yani Vault’u dev mode da başlattığımızda aslında otomatik olarak admin yetkilerine sahip root kullanıcı olarak login olmuştuk , fakat non-dev bir kurulumda önce authenticate olmamız gerekiyor.
» Vault’un Authentication için tabiri şu , Authentication bir Vault kullanıcısına kimlik atama mekanizmasıdır . Bu kullanıcı ile ilişkilendirilen Access Control(erişim kontrolü) ve Permissions(yetkiler) ise Authorization’dır.
» Vault’un bir diğer esnek noktalarından birisi de bu başlıkta bahsedeceğimiz Auth Method’lardır(Kimlik Doğrulama Yöntemleri).Bu yapı ile sağlamak istedikleri şey organizasyon için hangi yapı uygunsa gel Vault’a onun ile authenticate ol.
» Authentication’ı biraz daha teknik açıklayacak olursak Vault açısından , Authentication kullanıcı veya makine tarafından sağlanan bilginin doğrulanıp eşleşen policy’lerin atanıp Vault Token’a dönüştürülmesi işlemidir.
» Vault’da varsayılan olarak Token authentication methodu enabled gelir ve disable edilemez.Biz vault server -dev komutuyla beraber dev serveri başlattığımızda , server Root Token’ı yazar.Bu Root Token Vault’u konfigüre edebilmek için oluşturulan ilk erişim tokenidir ve root ayrıcalıklara sahiptir dolayısıyla Vault içerisinde istediği işlemi gerçekleştirebilir.
» İstersek vault token create komutuyla beraber daha çok token oluşturabiliriz.
$ vault token create
Key Value
--- -----—
token s.iyNUhq8Ov4hIAx6snw5mB2nL
token_accessor maMfHsZfwLB6fi18Zenj3qh6
token_duration ∞
token_renewable false
token_policies [“root”]
identity_policies []
policies [“root”]» Varsayılan olarak bu komut mevcut tokenimizin child tokenini oluşturur yani child token mevcut tokenimizin sahip olduğu tüm policylere kalıtım yoluyla sahip olur. Buradaki child token konsepti önemli çünkü tokenlerin her zaman bir parent tokenı vardır ve parent token iptal edilirse child tokenları da tek bir işlemle iptal edilir.Bu işlem bir kullanıcının erişimi silindiğinde bu kullanıcının oluşturmuş olduğu tüm sub-tokenlerin (alt token) de silinmesini kolaylaştırır.
» Token ile authenticate olabilmek için vault login komutundan faydalanacağız.Bu işlem ile beraber Token’ ımız verify (doğrulanacak)edilecek ve bu token’a hangi policylerin atandığı konusunda bizi bilgilendirecek.
$ vault login s.iyNUhq8Ov4hIAx6snw5mB2nLSuccess! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run “vault login”
again. Future Vault requests will automatically use this token.Key Value
--- -----
token s.iyNUhq8Ov4hIAx6snw5mB2nL
token_accessor maMfHsZfwLB6fi18Zenj3qh6
token_duration ∞
token_renewable false
token_policies [“root”]
identity_policies []
policies [“root”]
» Token’ımız oluşturulduktan sonra istediğimiz zaman revoke edebiliriz.
$ vault token revoke s.V6T0DxxIg5FbBSre61y1WLgm
Success! Revoked token (if it existed)» Burada kısa bir not düşmekte fayda var daha önceki revoke işlemini gerçekleştirirken vault lease revoke komutunu kullanmıştık bu komut sadece lease’leri revoke etmek için kullanılır , tokenları için ise vault token revoke komutu kullanılır.
» Şimdi tekrardan Root Token’ımız ile login olalım.
$ vault login $VAULT_DEV_ROOT_TOKEN_IDNOT: Önerilen modelde operatörler, kullanıcılar ve makineler için
Vault tokenları oluşturmak için token create komutunu kullanmamalıdır bunun yerine kullanıcılar ve makineler , konfigüre edilmiş herhangi bir Vault Auth methodları örneğin Gitlab,LDAP,AppRole vs gibi kullanarak Vault’a authenticate olmalıdır.
» Şimdi gelelim bu Auth Method kavramının ne olduğuna. Vault’ un bir çok Auth Method’u desteklediğini söylemiştik fakat kullanmadan önce Secret Enginelerdeki gibi enable edilmeleri gerekiyor. Auth Method’ların enable edilip konfigüre edilmesi security ekibi veya operatör tarafından yapılmalı.
» Örneğimizde olarak Vault’a Github ile authenticate olmayı deneyeceğiz.
$ vault auth enable -path=github github
Success! Enabled github auth method at: github/Secret Engine'deki default path mantığı burada da geçerli dolayısıyla iki komut da aynı işi yapıyor aslında.$ vault auth enable github
» Tıpkı Secret Engine’ler gibi Auth Method’ların da bir tipi ve bir path’i vardır . Fakat aradaki fark Auth Method’lar enable edilen root router’a her zaman auth/ prefixi ekler yani yukarıdaki örneği baz alırsak root router’ımız github fakat bu Auth Method’a erişim için kullanacağımız path auth/github olacaktır.Ardından bu Auth Method’un hangi pathlere sahip olduğunu öğrenmek için vault path-help komutundan da faydalanabileceğimizi unutmayalım.
» Her Auth Method’un kendine özgü konfigürasyon seçenekleri vardır , Github Auth Method’u enable ettikten sonra hangi organizasyon kullanıcıların bunun parçası olacağını söylememiz gerek.
$ vault write auth/github/config organization=hashicorp
Success! Data written to: auth/github/config» Bu komutla beraber Vault’a authentication datasını Github’daki hashicorp organizasyonundan çekeceğini söyledik.Daha sonra organizasyon içerisindeki takımları policyler ile eşleştiriyoruz.
$ vault write auth/github/map/teams/my-team value=default,my-policy Success! Data written to: auth/github/map/teams/my-team» Yine bu komutla beraber my-team takımına ait kullanıcılarına default ve my-policy policylerinin atanması gerektiğini söyledik.
» Sistemde hangi Auth Method’ların aktifleştirildiğini ve mevcut olduğunu görmek için vault auth list komutundan faydalanabiliriz.
$ vault auth list
Path Type Description
---- ---- -----------
github/ github n/a
token/ token token based credentials» Şimdi Github Auth Method’u konfigüre ettik fakat nasıl login olacağımızı halen bilmiyoruz , bunun için vault auth help komutundan faydalanalım bu komut Auth Method’un tipini veya path değerini parametre olarak alır.
$ vault auth help githubUsage: vault login -method=github [CONFIG K=V…]The GitHub auth method allows users to authenticate using a GitHub
personal access token. Users can generate a personal access token from the
settings page on their GitHub account.Authenticate using a GitHub token:$ vault login -method=github token=abcd1234Configuration:mount=<string>
Path where the GitHub credential method is mounted. This is usually
provided via the -path flag in the “vault login” command, but it can be
specified here as well. If specified here, it takes precedence over the
value for -path. The default value is “github”.token=<string>
GitHub personal access token to use for authentication
» Yardım çıktısına göre Github personal access tokenımızımızı vault login komutunun token parametresine geçerek login olabiliyoruz buradaki dikkat edin flag demedim parametre dedim mesela -method bir flag fakat token burada bir parametre görevi görür.
$ vault login -method=githubGitHub Personal Access Token (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run “vault login”
again. Future Vault requests will automatically use this token.Key Value
--- -----
token s.DNtKCjVQ1TxAzgMqtDuwjjC2
token_accessor e7zLJuPg2tLpav66ZSu5AyDC
token_duration 768h
token_renewable true
token_policies [default my-policy]
token_meta_org hashicorp
token_meta_username my-user
» Çıktıda gösterildiği gibi Vault , ortaya çıkan token’ı token yardımcısına kaydetti dolayısıyla tekrardan login olmamıza gerek kalmadı.
» Şimdi demomuza devam edebilmek için tekrardan Root Token ile login olalım.
$ vault login $VAULT_DEV_ROOT_TOKEN_ID» Yine bence çok güzel bir özellik , enable edilen Auth Method tarafından yapılan tüm loginleri revoke edebiliyoruz.
$ vault token revoke -mode path auth/github» Eğer istersek Auth Method’u komple disable edebiliriz.
$ vault auth disable github
Success! Disabled the auth method (if it existed) at: github/Policies
» Vault’da Policy’ler ile kullanıcıların neye erişelebileceklerini kontrol edebiliriz.Önceki bölümde Vault’un authentication yapısını öğrenmiştik şimdi ise authorization nasıl hallediliyor onu öğreneceğiz.
» Authentication için Vault’un enable edilebilir ve kullanılabilir bir çok seçeneği veya methodu var.Vault her zaman authorization ve policyler için aynı formatı kullanır.Tüm Auth Method’lar kimlikleri Vault ile yapılandırılan core policyler ile eşleştirir.
» Vault da silinemeyecek bazı built-in policyler vardır.Örneğin root ve default policyleri zorunludur ve silinemez.Default policy tüm tokenlere dahil edilen bazı ortak izinleri içerir.Root policy ise token’a süper admin izinleri verir tıpkı linux makinelerindeki root kullanıcısı gibi.
aslında komutun çıktısı çok daha uzundu fakat kesmek zorunda kaldım o yüzden siz kendi bilgisayarınızda denediğinizde çok daha fazla olduğunu teyit edebilirsiniz .
» Policy Format’ından bahsedelim , aslında yukarıdaki fotoğraflarda neye benzediğini görmüş olduk fakat biraz detay verelim.Policy’ler HCL dilinde yazılır, fakat JSON yazmamızın önünde de bir engel yok çünkü JSON’ı da destekler.İşte örnek bir Policy.
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path “secret/data/*” {
capabilities = [“create”, “update”]
}
path “secret/data/foo” {
capabilities = [“read”]
}» Bu Policy ile beraber kullanıcı secret/data path’ ine herhangi bir Secret’ı yazabilirken secret/data/foo path’ inde sadece okumaya izni vardır.
NOT: Policy’ler default olarak deny’ dır(reddedilir) , dolayısıyla Policy’lerde belirtilmemiş herhangi bir path’e erişim izni verilmez.
» Vault içerisinde Policy formatını otomatik olarak düzenleyen bir komuta da sahiptir. vault policy fmt <policy> komutu yardımıyla hem otomatik formatlama yapabiliriz hem de syntax hatalarını kontrol edebiliriz.
$ vault policy fmt my-policy.hcl» Policy formatı , erişim kontrolünü belirlemek için API yolunda bir ön-ek eşleme sistemi kullanır.(prefix matching system).En belirgin tanımlı politika, tam eşleme veya en uzun ön ekli glob eşleşmesi olarak kullanılır.
» Şimdi ilk policy’imizi yazalım.Bunun için vault policy write komutundan faydalanacağız.Bir dosyayı parametre alabildiğini STDIN üzerinden EOF file’ı da parametre olarak geçebiliriz.
# File'ı parametre olarak geçtiğimiz kullanımı
$ vault policy write my-policy my-policy.hcl
Success! Uploaded policy: my-policy# STDIN üzerinden EOF file olarak geçtiğimiz kullanımı
$ vault policy write my-policy -<<EOF
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
capabilities = ["create", "update"]
}path "secret/data/foo" {
capabilities = ["read"]
}
EOF
» İstersek Vault’daki tüm policyleri aşağıdaki komutla listeleyebiliriz.
$ vault policy list
default
my-policy
root» Eğer Policy’nin içeriğini görüntülemek istersek vault policy read komutundan faydalanırız.
$ vault policy read my-policy# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path “secret/data/*” {
capabilities = [“create”, “update”]
}path “secret/data/foo” {
capabilities = [“read”]
}
» Şimdi gelelim policy’imizi test etmeye .
- vault secrets enable -path=secret/ kv-v2 → kv-v2 tipinde bir Secret Engine create ediyoruz.
- vault token create -policy=my-policy → Yazdığımız policy’nin atanacağı bir token oluşturuyoruz.Komutun çıktısındaki token değerini kaydediyoruz.
- vault login s.X6gvFko7chPilgV0lpWXsdeu
- vault kv put secret/creds password=”my-long-password” → Policy’imiz bize diyordu ki secret/data altına istediğini yazabilirsin dolayısıyla bu komutun başarılı olması gerek. Burada bir şey dikkatinizi çekmiş olmalı, o da Policy’i yazarken secret/data kullanmıştık fakat put işlemi yaparken secret/creds şeklinde değeri koyduk /data’yı kullanmadık , bu kv-v2 tipindeki Secret Engine’imizin özelliğidir vault kv komutlarını kullanırken bu tip Secret Engine için /data ‘ yı görmezden gelebiliriz.
- vault kv put secret/foo robot=beepboop → Fakat Policy’mizde secret/foo path’inden sadece okuma yapabileceğimizi belirtmiştik dolayısıyla bu komutun fail ettiğini göreceksiniz.
- Ayrıca Root Token ile tekrardan login olmadığınız sürece herhangi bir Policy’leri listeme(vault policy list) , Secret Engine’leri listeme(vault secrets list) gibi işleri de yapamayacağız.
Yazımızının tutarlı şekilde devam edebilmesi için tekrardan Root Token ile login oluyoruz.
$ vault login $VAULT_DEV_ROOT_TOKEN_IDNOT: Vault bir çok Auth Method’u enable ettiğin authentication’ın aksine tek politika otoritesidir.Herhangi bir enable edilen Auth Method mutlaka kimlikleri bu core policyler ile eşleştirmelidir.
Deploy Vault
» Bence şimdi bu eğitim serisinin en eğlenceli ve bilgilendirici kısmına geldik.Bu noktaya kadar hep dev mode da çalıştık bu bize ne sağladı otomatik olarak Vault’a login olduk root token ile , bizim için in-memory backend ayarlandı.Şimdi ise gerçek bir ortamda bu süreçleri nasıl yöneteceğimizi öğreneceğiz ve daha önceden bahsettiğimiz initializing ve unsealing süreçlerini manuel olarak yapacağız.
» Yazının bu noktasına kadar belki dev mode’da Vault Server ‘ i nasıl başlattığımızı bir hatırlayalım , bunu yapabilmek için vault server -dev komutunu çalıştırmak yeterli olmuştu.Şimdi ise Vault Server için bir konfigürasyon dosyası yazacağız ve bunun ile başlamasını sağlayacağız.Yine bu konfigürasyon dosyasının dili olarak HCL kullanacağız.
# Bu içerikle beraber bir config.hcl dosyayı oluşturalım, HCL dilini kullanarak oluşturduğumuz dosyaların uzantısı .hcl ' dir.storage “consul” {
address = “127.0.0.1:8500”
path = “vault/”
}listener “tcp” {
address = “127.0.0.1:8200”
tls_disable = 1
}# bu kısım normal tutorialda yok ben ek bilgi olsun diye eklemek istedim.
telemetry {
statsite_address = "127.0.0.1:8125"
disable_hostname = true
}
» Aslında ilk bakışta bu ayarların ne manaya geldiğini bilmesek bile konfigürasyonun isimlerinden bir şeyler çıkarmak mümkün.Yani mesela hiç bilmeden bile storage olarak in-memory’ den farklı bir kaynak kullanılıyor , localhost üzerinde 8200 portunda non-TLS dinleme yapılıyor diyebiliriz şimdilik Telemetry’nin ne olduğunu bilemeyeceğiz tabiki.Ve aslında oldukça basit şekilde doğru da ifade ettik ama biraz detaylandıralım.Mesela benim gibi rahat edemeyip buradaki konfigürasyon değerlerinin anlamlarına ve başka hangi değerlerin var olduğuna bakmak isterseniz buraya göz atabilirsiniz.
- storage → Bu kısım Vault’ un storage amaçlı kullandığı fiziksel sistem.Bu noktaya kadar dediğimiz gibi hep in-memory çalıştık fakat bu örnekte Vault ile mükemmel ikili olan production-ready(prod hazır) Consul’u backend olarak kullanacağız. Bu ayar sayesinde de Consul’u backend olarak vault/ path’ inde kullanmasını istiyoruz.
- listener → Aslında hiçbir şey bilmeden bu field hakkında yaptığımız yorum tamamen doğruydu, Vault’ un API için nasıl dinleyeceğini belirtiyoruz, bu örnekte non-TLS olarak localhost üzerinde 8200 portunu dinleyeceğini belirttik.
» Şimdi Consul’u backend olarak kullanabilmek için bir dev mode da bir Consul agent başlatalım.Bu kısımda Consul ile ilgili ek bilgi vermeyeceğim fakat Consul ile ilgili daha çok bilgiye ulaşmak isterseniz buraya göz atabilirsiniz.
$ consul agent -dev» Yukarıda belirttiğimiz config.hcl dosyamızı Vault Server’i başlatırken kullanması için -config flag’ine parametre olarak vereceğiz.
$ vault server -config=config.hcl==> Vault server configuration:Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Listener 1: tcp (addr: “127.0.0.1:8200”, cluster address: “127.0.0.1:8201”, max_request_duration: “1m30s”, max_request_size: “33554432”, tls: “disabled”)
Log Level: info
Mlock: supported: false, enabled: false
Recovery Mode: false
Storage: consul (HA available)
Version: Vault v1.3.2==> Vault server started! Log data will stream in below:
» Bu noktada hemen bir şey dikkatinizi çekmiş olmalı , dev mode’da çalıştırdığımız Vault Server’in çıktısında Unseal Key ve Root Token değerleri de gösteriliyordu çünkü otomatik olarak initializing ve unsealing işlemleri yapılmıştı , burada bu işlemi manuel olarak yapmak durumdayız.Dolayısıyla bir Vault Server’i başlattıktan sonra yapılması gereken ilk adım onu initialize etmektir.Şimdi bunu nasıl yapabileceğimize bakalım.
» Initialization aslında Vault’u konfigüre etme işlemidir ve Vault’un daha önce kullanmadığı yeni bir backende karşı başlatıldığında sadece bir kez gerçekleşir.HA mode’ da çalıştırıldığında da server başına değil cluster başına bir kez gerçekleşir.
» Initialization sırasında , encryption keyler ve unseal keyler oluşturulur, initial root token oluşturulur , bunlar gerçekten çok önemliler :)
$ vault operator initUnseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOm
Unseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiS
Unseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chA
Unseal Key 4: 0cZE0C/gEk3YHaKjIWxhyyfs8REhqkRW/CSXTnmTilv+
Unseal Key 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2CkInitial Root Token: s.KkNJYWF5g0pomcCLEmDdOVCWVault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.Vault does not store the generated master key. Without at least 3 key to
reconstruct the master key, Vault will remain permanently sealed!It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See “vault operator rekey” for more information.
» Dediğim gibi bu çıktı bize çok önemli iki parçayı içerir , biri unseal keys diğeri ise initial root token.Bu verilerin tümünün Vault tarafından bilindiği ve unseal keylerin birbirine bu kadar yakın olması gereken tek zamandır.Şimdi bu tabirler böyle havada kalıyor gibi oluyor olabilir initializing ve unsealing süreçleri için verdiğim linklere girdiğinizde bir tık daha bu terimler anlam kazanabilir. Başlangıç eğitim serisi olduğu için bu keyleri şimdilik herhangi bir yerde saklayabiliriz ancak Vault bunlar için Vault’un PGP ve Keybase.io ‘ yu öneriyor.Biz unsealing işlemleri ile devam edelim.
» Ben ilk başta merak edip unseal’in Türkçe manasına bakmıştım siz de bakarsanız şöyle bir açıklama göreceksiniz ve bence buradaki en uygun anlamı mühür kırmak. Oradaki transt komutunun ne olduğunu merak ederseniz de aslında translate-shell tool’ unun kendim için oluşturduğum bir aliası.
Her initialize edilmiş Vault Server sealed state’de başlar yani mühürlü durumdadır hatırlarsanız vault status komutuyla bu initialize ve seal durumlarını görüntülemiştik , bu da şu demek aslında Vault üzerinde mühürlü durumdayken hiçbir işlem yapamayız mutlaka bu mührün kırılması gerek.Biraz daha teknik konuşmak gerekirse aslında Vault fiziksel storage’a ulaşabilirken buradan herhangi bir okuma yapamaz durumda çünkü nasıl decrypt edeceğini bilmiyor datayı dolayısıyla buradaki datayı nasıl decrypt edeceğini Vault’a öğretmek için unsealing işlemini gerçekleştirmeliyiz.
» Vault’u unseal edebilmek için unseal key’lerin eşik sayısı kadarına sahip olmalıyız.Şimdi yukarıdaki komutun çıktısında şöyle bir yazı var.
Vault initialized with 5 key shares and a key threshold of 3.
Bu demek oluyor ki Vault’u unseal edebilmek için oluşturulan bu 5 keyden 3'üne ihtiyacımız var.
$ vault operator unsealUnseal Key (will be hidden):
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed true
Total Shares 5
Threshold 3
Unseal Progress 1/3
Unseal Nonce d3d06528-aafd-c63d-a93c-e63ddb34b2a9
Version 1.3.4
HA Enabled true
» Unseal key’lerin birini girdik ve dikkat etmek gerekir ki unseal progress değeri 1/3 şeklinde güncellendi fakat hala Vault sealed durumda yani unseal işlemini bitirebilmek için diğer 2 key’i daha girmeliyiz.Yani Shamir’s Secret Sharing algorithmin doğası gereği Vault bu key’in doğru key olduğu ancak threshold değerindeki key sayısına ulaştığında anlayabilecek.Bu süreç aslında demoyu uzattığı için bu değerleri aslında biz belirleyebiliyoruz yani kaç tane unseal key oluşturulacak ve kaç tanesi ile Vault unseal edilebilir belirtebiliyoruz ki ben demolarda bunların ikisini de 1 olarak belirtiyorum .
vault operator init --help --> dediğinizde aşağıdaki iki flag bu amaç için kullanılıyor.
» Unsealing işlemi bittikten sonra Vault’un statüsü şu şekilde olmalı.
Key Value
--— -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.3.4
Cluster Name vault-cluster-df0d8ee9
Cluster ID c91bc0f4–3500–8293–23f4-ab6e1ec317a3
HA Enabled true
HA Cluster n/a
HA Mode standby
Active Node Address <none>Vault’u unseal ettikten sonra artık üzerinde çalışmak için özgürüz , hemen initial root token’ımız ile login olalım.
$ vault login s.KkNJYWF5g0pomcCLEmDdOVCW
Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run “vault login” again. Future Vault requests will automatically use this token.
Key Value
--- -----
token s.KkNJYWF5g0pomcCLEmDdOVCW
token_accessor 9jZ4x92RbzLqwLPlb9rVAMY9
token_duration ∞
token_renewable false
token_policies ["root"]
identity_policies []
policies ["root"]» Bu arada root kullanıcı olarak Vault’ reseal de edebiliriz bunun için vault operator seal komutunu kullanabiliriz.Bu acil bir durumda Vault’u kilitlemek için kullanılır.
Aslında son olarak HTTP API’ye detaylı bir göz atmak istiyordum fakat yeterince uzun olduğu ve gerekli bölümleri kapsayıp öğrendiğimizi düşündüğüm için burada kesiyorum fakat buradan hem eğitim serisine ulaşabilir buradan da resmi sitesindeki HTTP API için kaynağa ulaşabilirsiniz.
Umarım faydalı olur..
