├── DOCUMENTATION.md └── README.md /DOCUMENTATION.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | -------------------------- 2 | **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](https://www.vaultproject.io/docs/index.html) version of the Vault website. 3 | 4 | -------------------------- 5 | 6 | # Vault 7 | 8 | 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ş](https://www.vaultproject.io/intro/index.html) bölümüyle başlayın ve [Başlarken kılavuzuna](https://www.vaultproject.io/intro/getting-started/install.html) ile devam edin. 9 | 10 | 11 | ## Vault Başlangıç Kılavuzu 12 | 13 | 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. 14 | 15 | ### Vault nedir? 16 | 17 | 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. 18 | 19 | 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. 20 | 21 | Vault un temel özellikleri şunlardır: 22 | 23 | #### Gizli Bilgileri Güvenli Şekilde Depolama: 24 | 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. 25 | 26 | #### Değişiklik Arz Eden Gizli Veriler: 27 | 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. 28 | 29 | #### Veri Şifreleme: 30 | 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. 31 | 32 | #### Kullanım Süresi ve Yenileme: 33 | 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. 34 | 35 | #### İptal: 36 | 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. 37 | 38 | 39 | ### Kullanım Örnekleri 40 | 41 | 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. 42 | 43 | #### Genel Depolama Alanı 44 | 45 | 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. 46 | 47 | 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. 48 | 49 | #### Kimlik Bilgileri Depolama Alanı 50 | 51 | "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. 52 | 53 | #### API Anahtar Üretimi 54 | 55 | ##### Vault yazılımının "dinamik veri" özelliği kodlama için idealdir: 56 | 57 | Ö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. 58 | 59 | 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. 60 | 61 | #### Veri şifreleme 62 | 63 | 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. 64 | 65 | 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. 66 | 67 | ### Kullanım 68 | 69 | #### İlk Adım 70 | 71 | Önce makinenize Vault kurulmalıdır. Vault, tüm desteklenen platformlar ve mimariler için [ikili paket olarak](https://www.vaultproject.io/downloads.html) 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](https://www.vaultproject.io/docs/install/index.html) göz atabilir. 72 | 73 | #### Kurulum 74 | 75 | Vault yazılımını yüklemek için, sisteminize [uygun paketi bulun](https://www.vaultproject.io/downloads.html) ve indirin. Vault bir zip dosyası olarak paketlenmiştir. 76 | 77 | 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. 78 | 79 | 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](https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux) bakın. Windows'ta PATH ayarlama yönergeleri de [bu sayfada](https://stackoverflow.com/questions/1618280/where-can-i-set-path-to-make-exe-on-windows) bulunmaktadır. 80 | 81 | #### Doğrulama 82 | 83 | 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: 84 | 85 | ```shell 86 | $ vault 87 | usage: vault [-version] [-help] [args] 88 | 89 | Common commands: 90 | delete Delete operation on secrets in Vault 91 | path-help Look up the help for a path 92 | read Read data or secrets from Vault 93 | renew Renew the lease of a secret 94 | revoke Revoke a secret. 95 | server Start a Vault server 96 | status Outputs status of whether Vault is sealed and if HA mode is enabled 97 | write Write secrets or configuration into Vault 98 | 99 | All other commands: 100 | audit-disable Disable an audit backend 101 | audit-enable Enable an audit backend 102 | audit-list Lists enabled audit backends in Vault 103 | auth Prints information about how to authenticate with Vault 104 | auth-disable Disable an auth provider 105 | auth-enable Enable a new auth provider 106 | init Initialize a new Vault server 107 | key-status Provides information about the active encryption key 108 | mount Mount a logical backend 109 | mount-tune Tune mount configuration parameters 110 | mounts Lists mounted backends in Vault 111 | policies List the policies on the server 112 | policy-delete Delete a policy from the server 113 | policy-write Write a policy to the server 114 | rekey Rekeys Vault to generate new unseal keys 115 | remount Remount a secret backend to a new path 116 | rotate Rotates the backend encryption key used to persist data 117 | seal Seals the vault server 118 | ssh Initiate a SSH session 119 | token-create Create a new auth token 120 | token-renew Renew an auth token if there is an associated lease 121 | token-revoke Revoke one or more auth tokens 122 | unmount Unmount a secret backend 123 | unseal Unseals the vault server 124 | version Prints the Vault version 125 | ``` 126 | 127 | Eğ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. 128 | 129 | Aksi takdirde, Vault kurulu ve çalışmaya hazır! 130 | 131 | ### Vault Sunucusunun Başlatılması 132 | 133 | Vault kurulu olduğunda bir sonraki adım Vault sunucusunu başlatılmasıdır. 134 | 135 | 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. 136 | 137 | Bu sayfada, sunucunun nasıl başlatıldığını anlamak için Vault sunucusunu başlatacak ve etkileşimde bulunacağız. 138 | 139 | #### Geliştirici Özellikleri İle Sunucuyu Başlatma 140 | 141 | İ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. 142 | 143 | Vault geliştirici sunucusunu başlatmak için şunu çalıştırın: 144 | 145 | ```shell 146 | $ vault server -dev 147 | WARNING: Dev mode is enabled! 148 | 149 | In this mode, Vault is completely in-memory and unsealed. 150 | Vault is configured to only have a single unseal key. The root 151 | token has already been authenticated with the CLI, so you can 152 | immediately begin using the Vault CLI. 153 | 154 | The only step you need to take is to set the following 155 | environment variable since Vault will be talking without TLS: 156 | 157 | export VAULT_ADDR='http://127.0.0.1:8200' 158 | 159 | The unseal key and root token are reproduced below in case you 160 | want to seal/unseal the Vault or play with authentication. 161 | 162 | Unseal Key: 2252546b1a8551e8411502501719c4b3 163 | Root Token: 79bd8011-af5a-f147-557e-c58be4fedf6c 164 | 165 | ==> Vault server configuration: 166 | 167 | Log Level: info 168 | Backend: inmem 169 | Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled") 170 | 171 | ... 172 | ``` 173 | 174 | 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. 175 | 176 | 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. 177 | 178 | Geliştirici sunucusu ile ilgili önemli nokta, yalnızca geliştirme amaçlı olmasıdır. 179 | 180 | > Not: Geliştirici sunucusunu gerçek bir ortamda (production) çalıştırmayın. 181 | 182 | 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. 183 | 184 | Geliştirici sunucusunu çalışırken: 185 | 186 | 1. Yeni bir terminal oturumu açın. 187 | 188 | 2. `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. 189 | 190 | 3. 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. 191 | 192 | 4. Adım 3 ile aynı işlemi yapın, ancak `root` anahtarı ile yapın. Bunu daha sonra kullanacağız. 193 | 194 | #### Sunucunun Çalıştığını Doğrulayın 195 | 196 | `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ıdaki`export VAULT_ADDR='....` komutunu düzgün bir şekilde yürüttüğünüzden emin olun. 197 | 198 | Başarılı olursa, çıktı aşağıdaki gibi görünmelidir: 199 | 200 | ```shell 201 | $ vault status 202 | Sealed: false 203 | Key Shares: 1 204 | Key Threshold: 1 205 | Unseal Progress: 0 206 | 207 | High-Availability Enabled: false 208 | ``` 209 | 210 | Çı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. 211 | 212 | Bu çıktının daha sonra rehberde ne anlama geldiğini anlatacağız. 213 | 214 | 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. 215 | 216 | ### İlk Gizli Veri 217 | 218 | Şimdi geliştirci sunucumuz ayakta ve çalışıyor. İlk gizli verimizi yazıp okuyabiliriz. 219 | 220 | 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. 221 | 222 | 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. 223 | 224 | #### Gizli Bir Veriyi Yazma 225 | 226 | Hadi ilk gizli verimizi yazalım. Bu işlemi Aşağıda gösterildiği gibi `vault write` komutuyla yapıyoruz: 227 | 228 | ```shell 229 | $ vault write secret/hello value=world 230 | Success! Data written to: secret/hello 231 | ``` 232 | 233 | Bu, 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. 234 | 235 | İsterseniz çoklu veri parçaları halinde yazabilirsiniz: 236 | 237 | ```shell 238 | $ vault write secret/hello value=world excited=yes 239 | Success! Data written to: secret/hello 240 | ``` 241 | 242 | `vault 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](https://www.vaultproject.io/docs/commands/read-write.html) bakın. 243 | 244 | > Uyarı: Belgeler, `anahtar=değer` temelli 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. 245 | 246 | #### Gizli Bilgileri Okuma 247 | 248 | Tahmin edebileceğiniz gibi gizli veriler `vault read` komutu ile okunabilir: 249 | 250 | ```shell 251 | $ vault read secret/hello 252 | Key Value 253 | --- ----- 254 | refresh_interval 768h0m0s 255 | excited yes 256 | value world 257 | ``` 258 | 259 | Gördüğünüz gibi, yazdığımız değerler bize geri veriliyor. Vault veriyi depodan okuyor ve bizim için çözümlüyor. 260 | 261 | Çıktı biçimi, `awk` gibi bir araç ile Tabular olarak düzenlenmiş. 262 | 263 | Tabular çıktı biçime ek olarak, eğer `jq` gibi bir araçla çalışıyorsanız, verileri JSON formatında çıktı alabilirsiniz: 264 | 265 | ```shell 266 | $ vault read -format=json secret/hello 267 | { 268 | "request_id": "68315073-6658-e3ff-2da7-67939fb91bbd", 269 | "lease_id": "", 270 | "lease_duration": 2764800, 271 | "renewable": false, 272 | "data": { 273 | "excited": "yes", 274 | "value": "world" 275 | }, 276 | "warnings": null 277 | } 278 | ``` 279 | 280 | 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. 281 | 282 | 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: 283 | 284 | ```shell 285 | $ vault read -format=json secret/hello | jq -r .data.excited 286 | yes 287 | ``` 288 | 289 | #### Bir Gizli Veriyi Silme 290 | 291 | Artık gizli bir veriyi okuma ve yazmayı öğrendiğimize göre, silme işlemine geçebiliriz. Bunu `vault delete` ile yapabiliriz: 292 | 293 | ```shell 294 | $ vault delete secret/hello 295 | Success! Deleted 'secret/hello' if it existed. 296 | ``` 297 | 298 | ### Gizli Veri Yönetim Servisleri 299 | 300 | 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. 301 | 302 | 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](https://en.wikipedia.org/wiki/Hardware_security_module)'ye veri yazar ve okur. Vault olgunlaştıkça giderek daha fazla gizli veri yönetim servisi eklenecektir. 303 | 304 | Vault Gizli Veri Yönetim Servislerini Dosya Sistemine Çok Benzer Şekilde Kullanır: 305 | 306 | 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. 307 | 308 | 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. 309 | 310 | #### Gizli Veri Yönetim Servisi Tanımlama 311 | 312 | İ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. 313 | 314 | Gizli Veri Yönetim Servisi Tanımlama: 315 | 316 | ```shell 317 | $ vault mount generic 318 | Successfully mounted 'generic' at 'generic'! 319 | ``` 320 | 321 | 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. 322 | 323 | Depolama Tanımlarını `vault mounts` ile inceleyebilirsiniz: 324 | 325 | ```shell 326 | $ vault mounts 327 | Path Type Description 328 | generic/ generic 329 | secret/ generic generic secret storage 330 | sys/ system system endpoints used for control, policy and debugging 331 | ``` 332 | 333 | Gö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. 334 | 335 | 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. 336 | 337 | #### Gizli Veri Yönetim Servisini Kaldırma 338 | 339 | 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. 340 | 341 | ```shell 342 | $ vault unmount generic/ 343 | Successfully unmounted 'generic/' if it was mounted 344 | ``` 345 | 346 | Bir 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. 347 | 348 | #### Gizli Veri Yönetim Servisi Nedir? 349 | 350 | 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? 351 | 352 | Vault [sanal bir dosya sistemi](https://en.wikipedia.org/wiki/Virtual_file_system) 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) 353 | 354 | 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. 355 | 356 | 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. 357 | 358 | ### Gizli Bilgi Üretme - Dinamik Gizli Veri 359 | 360 | 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. 361 | 362 | 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. 363 | 364 | 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. 365 | 366 | > Not: Bu sayfayı başlatmadan önce, lütfen bir AWS hesabı için [kayıt](https://aws.amazon.com/) 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. 367 | 368 | #### AWS Gizli Veri Yönetim Servisini Tanımlama 369 | 370 | İ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: 371 | 372 | 373 | ```shell 374 | $ vault mount aws 375 | Successfully mounted 'aws' at 'aws'! 376 | ``` 377 | 378 | 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. 379 | 380 | #### AWS Gizli Veri Yönetim Servisini Yapılandırma 381 | 382 | 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. 383 | 384 | Depolama birimini yapılandırmak için, `vault write` komutunu `aws/config/root` yolu üzerinde kullanacağız: 385 | 386 | ```shell 387 | $ vault write aws/config/root \ 388 | access_key=AKIAI4SGLQPBX6CSENIQ \ 389 | secret_key=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 390 | Success! Data written to: aws/config/root 391 | ``` 392 | 393 | Dinamik 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: 394 | 395 | ```shell 396 | $ vault read aws/config/root 397 | Error reading aws/config/root: Error making API request. 398 | 399 | URL: GET http://127.0.0.1:8200/v1/aws/config/root 400 | Code: 405. Errors: 401 | 402 | * unsupported operation 403 | ``` 404 | 405 | Kimlik 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. 406 | 407 | #### Rol Yaratmak 408 | 409 | 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. 410 | 411 | 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: 412 | 413 | ```json 414 | { 415 | "Version": "2012-10-17", 416 | "Statement": [ 417 | { 418 | "Sid": "Stmt1426528957000", 419 | "Effect": "Allow", 420 | "Action": [ 421 | "ec2:*" 422 | ], 423 | "Resource": [ 424 | "*" 425 | ] 426 | } 427 | ] 428 | } 429 | ``` 430 | 431 | 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: 432 | 433 | ```shell 434 | $ vault write aws/roles/deploy policy=@policy.json 435 | Success! Data written to: aws/roles/deploy 436 | ``` 437 | 438 | Vault'a bir IAM ilkesi yazmak için `aws/roles/` 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. 439 | 440 | #### Gizli Veri Üretme 441 | 442 | 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/` özel yolunu okuyun, burada ADI rolün adıdır: 443 | 444 | ```shell 445 | $ vault read aws/creds/deploy 446 | Key Value 447 | --- ----- 448 | lease_id aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5 449 | lease_duration 768h0m0s 450 | lease_renewable true 451 | access_key AKIAJFN42DVCQWDHQYHQ 452 | secret_key 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 453 | security_token 454 | ``` 455 | 456 | 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. 457 | 458 | 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. 459 | 460 | #### Gizli Veriyi İptal Etme 461 | 462 | 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. 463 | 464 | 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 : 465 | 466 | ```shell 467 | $ vault revoke aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5 468 | Success! Revoked the secret with ID 'aws/creds/deploy/0d042c53-aa8a-7ce7-9dfd-310351c465e5', if it existed. 469 | ``` 470 | 471 | 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. 472 | 473 | 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. 474 | 475 | ### Vault Yardım Menusu 476 | 477 | Ş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. 478 | 479 | 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. 480 | 481 | Bu sayfada, bu yardım sistemini nasıl kullanacağınızı öğreneceğiz. Vault'u kullanırken çok değerli bir araçtır. 482 | 483 | #### Gizli Veri Yönetim Servislerine Genel Bakış 484 | 485 | 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. 486 | 487 | Depolama birimi tanımlıyken `thevault path-help` komutunu deneyelim: 488 | 489 | ```shell 490 | $ vault path-help aws 491 | ## DESCRIPTION 492 | 493 | The AWS backend dynamically generates AWS access keys for a set of 494 | IAM policies. The AWS access keys have a configurable lease set and 495 | are automatically revoked at the end of the lease. 496 | 497 | After mounting this backend, credentials to generate IAM keys must 498 | be configured with the "root" path and policies must be written using 499 | the "roles/" endpoints before any access keys can be generated. 500 | 501 | ## PATHS 502 | 503 | The following paths are supported by this backend. To view help for 504 | any of the paths below, use the help command with any route matching 505 | the path pattern. Note that depending on the policy of your auth token, 506 | you may or may not be able to access certain paths. 507 | 508 | ^config/lease$ 509 | Configure the default lease information for generated credentials. 510 | 511 | ^config/root$ 512 | Configure the root credentials that are used to manage IAM. 513 | 514 | ^creds/(?P\w+)$ 515 | Generate an access key pair for a specific role. 516 | 517 | ^roles/(?P\w+)$ 518 | Read and write IAM policies that access keys can be made for. 519 | ``` 520 | 521 | `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. 522 | 523 | #### PATH Yardımı 524 | 525 | 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. 526 | 527 | ```shell 528 | $ vault path-help aws/creds/operator 529 | Request: creds/operator 530 | Matching Route: ^creds/(?P\w+)$ 531 | 532 | Generate an access key pair for a specific role. 533 | 534 | ## PARAMETERS 535 | 536 | name (string) 537 | Name of the role 538 | 539 | ## DESCRIPTION 540 | 541 | This path will generate a new, never before used key pair for 542 | accessing AWS. The IAM policy used to back this key pair will be 543 | the "name" parameter. For example, if this backend is mounted at "aws", 544 | then "aws/creds/deploy" would generate access keys for the "deploy" role. 545 | 546 | The access keys will have a lease associated with them. The access keys 547 | can be revoked by using the lease ID. 548 | ``` 549 | 550 | 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. 551 | 552 | Bu yolun ne yaptığının bir açıklaması da var. 553 | 554 | 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. 555 | 556 | ### Kimlik Doğrulama 557 | 558 | 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. 559 | 560 | 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. 561 | 562 | 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. 563 | 564 | #### Tokens - Erişim Anahtarları 565 | 566 | 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. 567 | 568 | 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. 569 | 570 | `vault token-create` komutunu kullanarak daha fazla `token` yaratabilirsiniz: 571 | 572 | ```shell 573 | $ vault token-create 574 | Key Value 575 | token c2c2fbd5-2893-b385-6fa5-30050439f698 576 | token_accessor 0c1c3317-3d58-17e5-c1a9-3f54fa26610e 577 | token_duration 0 578 | token_renewable true 579 | token_policies [root] 580 | ``` 581 | 582 | 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: `Token`ları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. 583 | 584 | Bir `token` yaratıldıktan sonra, `vault token-revoke` ile iptal edebilirsiniz: 585 | 586 | ```shell 587 | $ vault token-revoke c2c2fbd5-2893-b385-6fa5-30050439f698 588 | Success! Token revoked if it existed. 589 | ``` 590 | 591 | 592 | 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. 593 | 594 | Bir `token` ile kimlik doğrulaması yapmak için `vault auth` komutunu kullanın: 595 | 596 | 597 | ```shell 598 | $ vault auth d08e2bd5-ffb0-440d-6486-b8f650ec8c0c 599 | Successfully authenticated! The policies that are associated 600 | with this token are listed below: 601 | 602 | root 603 | ``` 604 | 605 | Bu 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. 606 | 607 | #### Kimilik Doğrulama Sistemleri 608 | 609 | 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. 610 | 611 | Örnek olarak, GitHub'ı kullanarak kimlik doğrulamasını yapalım. Önce, GitHub Kimilik Doğrulama Sistemini etkinleştirin: 612 | 613 | ```shell 614 | $ vault auth-enable github 615 | Successfully enabled 'github' at 'github'! 616 | ``` 617 | 618 | 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. 619 | 620 | 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: 621 | 622 | ```shell 623 | $ vault write auth/github/config organization=hashicorp 624 | Success! Data written to: auth/github/config 625 | 626 | $ vault write auth/github/map/teams/default value=default 627 | Success! Data written to: auth/github/map/teams/default 628 | ``` 629 | 630 | Yukarı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. 631 | 632 | GitHub etkinleştirildiğine göre, artık `vault auth` kullanarak kimlik doğrulaması yapabiliriz: 633 | 634 | ```shell 635 | $ vault auth -method=github token=e6919b17dd654f2b64e67b6369d61cddc0bcc7d5 636 | Successfully authenticated! The policies that are associated 637 | with this token are listed below: 638 | 639 | default 640 | ``` 641 | 642 | İş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ı`](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) olmalıdır. 643 | 644 | Farkettiyseniz, komutları çalıştırmak için daha önce var olan `root` erişim anahtarı ile yeniden kimlik doğrulaması yapıldı. 645 | 646 | 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: 647 | 648 | ```shell 649 | $ vault token-revoke -mode=path auth/github 650 | ``` 651 | 652 | İş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. 653 | 654 | ```shell 655 | $ vault auth-disable github 656 | Disabled auth provider at path 'github'! 657 | ``` 658 | 659 | ### Erişim Kontrol Politikaları (ACLs) 660 | 661 | "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. 662 | 663 | 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. 664 | 665 | 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. 666 | 667 | #### Politika Formatı 668 | 669 | Vault'daki politikalar [HCL](https://github.com/hashicorp/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: 670 | 671 | 672 | ```hcl 673 | path "secret/*" { 674 | policy = "write" 675 | } 676 | 677 | path "secret/foo" { 678 | policy = "read" 679 | } 680 | 681 | path "auth/token/lookup-self" { 682 | policy = "read" 683 | } 684 | ``` 685 | 686 | 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. 687 | 688 | 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](https://www.vaultproject.io/docs/concepts/policies.html) bakın. 689 | 690 | Yukarıdaki Politikayı acl.hcl adlı bir dosyaya kaydedin. 691 | 692 | #### Erişim Politikası Yazmak 693 | 694 | Bir politika yazmak için `vault policy-write` komutunu kullanın: 695 | 696 | ```shell 697 | $ vault policy-write secret acl.hcl 698 | Policy 'secret' written. 699 | ``` 700 | 701 | `vault policies` ile kullanılabilen politikaları listeleyebilir ve `vault policies ` ile varolan bir politikanın içeriğini görebilirsiniz. Yalnızca `root` erişime sahip kullanıcılar bunu yapabilir. 702 | 703 | #### Politikaların Test Edilmesi 704 | 705 | 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. 706 | 707 | ```shell 708 | $ vault token-create -policy="secret" 709 | Key Value 710 | token d97ef000-48cf-45d9-1907-3ea6ce298a29 711 | token_accessor 71770cc5-14da-f0af-c6ce-17a0ae398d67 712 | token_duration 2764800 713 | token_renewable true 714 | token_policies [default secret] 715 | 716 | $ vault auth d97ef000-48cf-45d9-1907-3ea6ce298a29 717 | Successfully authenticated! 718 | token: d97ef000-48cf-45d9-1907-3ea6ce298a29 719 | token_duration: 2591938 720 | token_policies: [default, secret] 721 | ``` 722 | 723 | Artık, `secret/` için veri yazabildiğinizi test edebilirsiniz, tabi yalnızca `thesecret/foo` adresinden okuyabilirsiniz: 724 | 725 | ```shell 726 | $ vault write secret/bar value=yes 727 | Success! Data written to: secret/bar 728 | 729 | $ vault write secret/foo value=yes 730 | Error writing data to secret/foo: Error making API request. 731 | 732 | URL: PUT http://127.0.0.1:8200/v1/secret/foo 733 | Code: 403. Errors: 734 | 735 | * permission denied 736 | ``` 737 | 738 | Aynı zamanda politikaya göre sys'e erişiminiz yok, bu nedenle `vault mounts` gibi komutlar da kullanılamaz. 739 | 740 | #### Politikarı Kimlik Doğrulama Sistemleri İle Eşleştirme 741 | 742 | 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. 743 | 744 | 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/` adresini kullanarak takıma eşleştirme yaparız: 745 | 746 | ```shell 747 | $ vault write auth/github/map/teams/default value=secret 748 | Success! Data written to: auth/github/map/teams/default 749 | ``` 750 | 751 | GitHub için varsayılan ekip, hangi takımdan olursa olsun herkesin atandığı varsayılan politikayı kullanır. 752 | 753 | Diğer kimlik doğrulama sistemleri, politikaları kimlikle eşlemek için alternatif oluşturur, ancak benzer şekilde çalışır. 754 | 755 | ### Vault'u Gerçek Ortamda Çalıştırma 756 | 757 | 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. 758 | 759 | 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. 760 | 761 | #### Vault'un Yapılandırılması 762 | 763 | 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: 764 | 765 | ```hcl 766 | backend "consul" { 767 | address = "127.0.0.1:8500" 768 | path = "vault" 769 | } 770 | 771 | listener "tcp" { 772 | address = "127.0.0.1:8200" 773 | tls_disable = 1 774 | } 775 | ``` 776 | 777 | Bu yapılandırma dosyasında iki temel yapılandırma vardır: 778 | 779 | 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](https://www.consul.io) kullanıyoruz. 780 | 781 | 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. 782 | 783 | Ş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. 784 | 785 | 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](https://www.consul.io/intro/getting-started/install.html) takip etmeniz ve şu komutu kullanarak başlatmanız yeterlidir: 786 | 787 | ```shell 788 | $ consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -bind 127.0.0.1 789 | ``` 790 | 791 | 792 | #### Sunucuyu Başlatma 793 | 794 | Konfigü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. 795 | 796 | ```shell 797 | $ vault server -config=example.hcl 798 | ==> Vault server configuration: 799 | 800 | Log Level: info 801 | Backend: consul 802 | Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled") 803 | 804 | ==> Vault server started! Log data will stream in below: 805 | ``` 806 | 807 | 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. 808 | 809 | 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. 810 | 811 | Linux'ta Vault aşağıdaki hatayla başlamayabilir: 812 | 813 | ```shell 814 | $ vault server -config=example.hcl 815 | Error initializing core: Failed to lock memory: cannot allocate memory 816 | 817 | This usually means that the mlock syscall is not available. 818 | Vault uses mlock to prevent memory from being swapped to 819 | disk. This requires root privileges as well as a machine 820 | that supports mlock. Please enable mlock on your system or 821 | disable Vault from using it. To disable Vault from using it, 822 | set the `disable_mlock` configuration option in your configuration 823 | file. 824 | ``` 825 | 826 | Bu konuyla ilgili daha detaylı yönergeler için, Sunucu Yapılandırması'ndaki [disable_mlock tartışmasına](https://www.vaultproject.io/docs/configuration/index.html) bakın. 827 | 828 | #### Vault Önyükleme 829 | 830 | Ö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. 831 | 832 | Ö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: 833 | 834 | ```shell 835 | $ vault init 836 | Key 1: 427cd2c310be3b84fe69372e683a790e01 837 | Key 2: 0e2b8f3555b42a232f7ace6fe0e68eaf02 838 | Key 3: 37837e5559b322d0585a6e411614695403 839 | Key 4: 8dd72fd7d1af254de5f82d1270fd87ab04 840 | Key 5: b47fdeb7dda82dbe92d88d3c860f605005 841 | Initial Root Token: eaf5cc32-b48f-7785-5c94-90b5ce300e9b 842 | 843 | Vault initialized with 5 keys and a key threshold of 3! 844 | ... 845 | ``` 846 | 847 | Ö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. 848 | 849 | 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](https://www.vaultproject.io/docs/concepts/pgp-gpg-keybase.html) kullanma ile ilgili dokümanlara bakın. 850 | 851 | #### Seal/Unseal - Mühürleme/Mühür Açma 852 | 853 | 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. 854 | 855 | 856 | 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. 857 | 858 | 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`](https://en.wikipedia.org/wiki/Shamir%27s_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. 859 | 860 | Mühür Açma işlemine "vault unseal" ile başlayın: 861 | 862 | ```shell 863 | $ vault unseal 864 | Key (will be hidden): 865 | Sealed: true 866 | Key Shares: 5 867 | Key Threshold: 3 868 | Unseal Progress: 1 869 | ``` 870 | 871 | Geç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. 872 | 873 | 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. 874 | 875 | 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: 876 | 877 | ```shell 878 | $ vault unseal 879 | Key (will be hidden): 880 | Sealed: false 881 | Key Shares: 5 882 | Key Threshold: 3 883 | Unseal Progress: 0 884 | ``` 885 | 886 | `Sealed:false` Vault'un mühürlü olduğu anlamına gelir! 887 | 888 | `The Sealed:false` : Vault'un mühürlü olduğu anlamına gelir! 889 | 890 | 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. 891 | 892 | `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. 893 | 894 | 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. 895 | 896 | ### HTTP API üzerinde Kimlik Doğrulama 897 | 898 | 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. 899 | 900 | 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: 901 | 902 | ```shell 903 | $ curl http://127.0.0.1:8200/v1/sys/init 904 | ``` 905 | 906 | Bu istek bir JSON yanıtı döndürür: 907 | 908 | ```shell 909 | { "initialized": true } 910 | ``` 911 | 912 | #### Gizli Verilere REST API aracılığı ile Erişmek: 913 | 914 | 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](https://www.vaultproject.io/docs/auth/approle.html) 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. 915 | 916 | 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. 917 | 918 | ```shell 919 | backend "file" { 920 | path = "vault" 921 | } 922 | 923 | listener "tcp" { 924 | tls_disable = 1 925 | } 926 | ``` 927 | 928 | Bu dosyayı diske kaydedin ve vault sunucusunu şu komutu kullanarak çalıştırın: 929 | 930 | ```shell 931 | $ vault server -config=/etc/vault.conf 932 | ``` 933 | 934 | Bu noktada, tüm etkileşimlerimiz için vault API'yı kullanabiliriz. Örneğin, Vault'u şöyle başlatabiliriz: 935 | 936 | ```shell 937 | $ curl \ 938 | -X PUT \ 939 | -d "{\"secret_shares\":1, \"secret_threshold\":1}" \ 940 | http://127.0.0.1:8200/v1/sys/init 941 | ``` 942 | 943 | Yanıt aşağıdaki JSON çıktısına benziyor olmalı: 944 | 945 | ```shell 946 | { 947 | "root_token": "4f66bdfa-f5e4-209f-096c-6e01d863c145", 948 | "keys_base64": [ 949 | "FwwsSzMysLgYAvJFrs+q5UfLMKIxC+dDFbP6YzyjzvQ=" 950 | ], 951 | "keys": [ 952 | "170c2c4b3332b0b81802f245aecfaae547cb30a2310be74315b3fa633ca3cef4" 953 | ] 954 | } 955 | ``` 956 | 957 | 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. 958 | 959 | 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: 960 | 961 | ```shell 962 | $ export VAULT_TOKEN=4f66bdfa-f5e4-209f-096c-6e01d863c145 963 | ``` 964 | 965 | Mühür açma anahtarını (root erişim anahtarını içermez) kullanarak yukarıdan Vault'u HTTP API aracılığı açabilirsiniz: 966 | 967 | ```shell 968 | $ curl \ 969 | -X PUT \ 970 | -d '{"key": "FwwsSzMysLgYAvJFrs+q5UfLMKIxC+dDFbP6YzyjzvQ="}' \ 971 | http://127.0.0.1:8200/v1/sys/unseal 972 | ``` 973 | 974 | `FwwsSzM ... `'yi sizin elde ettiğiniz anahtarla değiştirmeniz gerektiğini unutmayın. Bu komut JSON yanıtı döndürür: 975 | 976 | ```shell 977 | { 978 | "cluster_id": "1c2523c9-adc2-7f3a-399f-7032da2b9faf", 979 | "cluster_name": "vault-cluster-9ac82317", 980 | "version": "0.6.2", 981 | "progress": 0, 982 | "n": 1, 983 | "t": 1, 984 | "sealed": false 985 | } 986 | ``` 987 | 988 | Artık kimlik doğrulama sistemlerinden herhangi birini etkinleştirilebilir ve yapılandırılabilirsiniz. Bu kılavuzun amacı doğrultusunda [AppRole](https://www.vaultproject.io/docs/auth/approle.html) kimlik doğrulamasını etkinleştireceğiz. 989 | 990 | AppRole kimlik doğrulamasını etkinleştirin: 991 | 992 | ```shell 993 | $ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" -d '{"type":"approle"}' http://127.0.0.1:8200/v1/sys/auth/approle 994 | ``` 995 | 996 | AppRole 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. 997 | 998 | Ş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. 999 | 1000 | ```shell 1001 | $ 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/testrole 1002 | ``` 1003 | 1004 | Varsayı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. 1005 | 1006 | ```shell 1007 | $ curl -X GET -H "X-Vault-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/auth/approle/role/testrole/role-id | jq . 1008 | ``` 1009 | 1010 | ```shell 1011 | { 1012 | "auth": null, 1013 | "warnings": null, 1014 | "wrap_info": null, 1015 | "data": { 1016 | "role_id": "988a9dfd-ea69-4a53-6cb6-9d6b86474bba" 1017 | }, 1018 | "lease_duration": 0, 1019 | "renewable": false, 1020 | "lease_id": "", 1021 | "request_id": "ef5c9b3f-e15e-0527-5457-79b4ecfe7b60" 1022 | } 1023 | ``` 1024 | 1025 | Bu komut, `testrole`'un altında yeni bir `secret ID` oluşturur. 1026 | 1027 | ```shell 1028 | $ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/auth/approle/role/testrole/secret-id | jq . 1029 | ``` 1030 | 1031 | ```shell 1032 | { 1033 | "auth": null, 1034 | "warnings": null, 1035 | "wrap_info": null, 1036 | "data": { 1037 | "secret_id_accessor": "45946873-1d96-a9d4-678c-9229f74386a5", 1038 | "secret_id": "37b74931-c4cd-d49a-9246-ccc62d682a25" 1039 | }, 1040 | "lease_duration": 0, 1041 | "renewable": false, 1042 | "lease_id": "", 1043 | "request_id": "c98fa1c2-7565-fd45-d9de-0b43c307f2aa" 1044 | } 1045 | ``` 1046 | 1047 | 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. 1048 | 1049 | ```shell 1050 | $ curl -X POST \ 1051 | -d '{"role_id":"988a9dfd-ea69-4a53-6cb6-9d6b86474bba","secret_id":"37b74931-c4cd-d49a-9246-ccc62d682a25"}' \ 1052 | http://127.0.0.1:8200/v1/auth/approle/login | jq . 1053 | ``` 1054 | 1055 | ```shell 1056 | { 1057 | "auth": { 1058 | "renewable": true, 1059 | "lease_duration": 2764800, 1060 | "metadata": {}, 1061 | "policies": [ 1062 | "default", 1063 | "dev-policy", 1064 | "test-policy" 1065 | ], 1066 | "accessor": "5d7fb475-07cb-4060-c2de-1ca3fcbf0c56", 1067 | "client_token": "98a4c7ab-b1fe-361b-ba0b-e307aacfd587" 1068 | }, 1069 | "warnings": null, 1070 | "wrap_info": null, 1071 | "data": null, 1072 | "lease_duration": 0, 1073 | "renewable": false, 1074 | "lease_id": "", 1075 | "request_id": "988fb8db-ce3b-0167-0ac7-1a568b902d75" 1076 | } 1077 | ``` 1078 | 1079 | 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. 1080 | 1081 | 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. 1082 | 1083 | ```shell 1084 | $ export VAULT_TOKEN="98a4c7ab-b1fe-361b-ba0b-e307aacfd587" 1085 | $ curl -X POST -H "X-Vault-Token:$VAULT_TOKEN" -d '{"bar":"baz"}' http://127.0.0.1:8200/v1/secret/foo 1086 | ``` 1087 | 1088 | Bu verilen JSON içeriğiyle "foo" adlı yeni bir gizli veri oluşturacaktır. Bu değeri aynı erşiim anahtarı ile okuyabiliriz: 1089 | 1090 | ```shell 1091 | $ curl -X GET -H "X-"thesVassult"-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/secret/foo | jq . 1092 | ``` 1093 | 1094 | Aşağıdaki gibi bir JSON yanıtı dönecektir: 1095 | 1096 | ```shell 1097 | { 1098 | "auth": null, 1099 | "warnings": null, 1100 | "wrap_info": null, 1101 | "data": { 1102 | "bar": "baz" 1103 | }, 1104 | "lease_duration": 2764800, 1105 | "renewable": false, 1106 | "lease_id": "", 1107 | "request_id": "5e246671-ec05-6fc8-9f93-4fe4512f34ab" 1108 | } 1109 | ``` 1110 | 1111 | Diğer kullanılabilir API talep adresleri ile ilgili daha fazla ayrıntı bilgi için [HTTP API' belgelerini](https://www.vaultproject.io/api/index.html) inceleyebilirsiniz. 1112 | 1113 | Tebrikler! Artık Vault ile çalışmak için gereken tüm temel bilgilere sahipsiniz. 1114 | 1115 | 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. 1116 | 1117 | 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. 1118 | 1119 | [Dokümantasyon](https://www.vaultproject.io/docs/index.html) - Dokümantasyon,Vault'un tüm özelliklerine ilişkin ayrıntılı bir referans kaynağıdır. 1120 | 1121 | 1122 | ## Vault Dokümantasyon 1123 | 1124 | ### Vault'u Kurun 1125 | 1126 | Vault kurulumu oldukça basittir. Vault kurulumunda iki yaklaşım vardır: 1127 | 1128 | 1. [Önceden Derlenmiş Dosya Kullanma](https://www.vaultproject.io/docs/install/index.html#precompiled-binaries) 1129 | 1130 | 2. [Kaynaktan yükleme](https://www.vaultproject.io/docs/install/index.html#compiling-from-source) 1131 | 1132 | 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. 1133 | 1134 | #### Önceden derlenmiş ikili dosyalar 1135 | 1136 | Önceden derlenmiş bir dosyayı yüklemek için, sisteminiz için uygun paketi [indirin.](https://www.vaultproject.io/downloads.html) Vault bir zip dosyası olarak paketlenmiştir. Farklı türde sistem paketleri sağlamak için kısa vadeli bir planımız yok. 1137 | 1138 | 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. 1139 | 1140 | 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. 1141 | 1142 | #### Kaynaktan Derleme 1143 | 1144 | 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). 1145 | 1146 | 1. Vault deposunu GitHub'dan GOPATH'a kopyalayın: 1147 | 1148 | ```shell 1149 | $ mkdir -p $GOPATH/src/github.com/hashicorp && cd $! 1150 | $ git clone https://github.com/hashicorp/vault.git 1151 | $ cd vault 1152 | ``` 1153 | 1154 | 2. Projeyi önyükleyin. Bu operasyon, Vault dosyasını derlemek için gerekli kütüphaneleri ve araçları indirecek ardından derleyecektir: 1155 | 1156 | ```shell 1157 | $ make bootstrap 1158 | ``` 1159 | 1160 | 3. Geçerli sisteminiz için Vault dosyasını oluşturun ve dosyayı `./bin/` dizinine yerleştirin. `make dev` yerel ortamınız için `vault`'u oluşturan bir kısayoldur (çapraz derleme yapmaz). 1161 | 1162 | ```shell 1163 | $ make dev 1164 | ``` 1165 | 1166 | #### Kurulumun Doğrulanması 1167 | 1168 | Vault 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. 1169 | 1170 | ```shell 1171 | $ vault -v 1172 | ``` 1173 | 1174 | ### Vault'un Derinlikleri 1175 | 1176 | Bu 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. 1177 | 1178 | > 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. 1179 | 1180 | 1181 | #### Mimari 1182 | 1183 | 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. 1184 | 1185 | > 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. 1186 | 1187 | #### Sözlük 1188 | 1189 | Mimariyi tanımlamadan önce, tartışılanları netleştirmek için terimler sözlüğü faydalı olacaktır: 1190 | 1191 | * **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. 1192 | 1193 | * **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. 1194 | 1195 | * **Gizli Veri Yönetim Servisi (Secret Backend)** - Gizli veri yönetim servisi, gizli verilerin yönetiminden sorumludur. `generic` gizli 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. 1196 | 1197 | * **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. 1198 | 1199 | * **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-password` servisi, kullanıcının kimliğini doğrulamak için bir kullanıcı adı ve parola kullanır. Alternatif olarak, `github` kimlik doğrulama servisi, kullanıcıların GitHub ile kimlik doğrulamasını sağlar. 1200 | 1201 | * **İ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. 1202 | 1203 | * **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. 1204 | 1205 | * **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. 1206 | 1207 | #### Üst Düzey Genel Bakış 1208 | 1209 | Vault hakkında yüksek düzeyde bir genel bakış şöyle görünür: 1210 | 1211 | ![Architecture Overview](https://www.vaultproject.io/assets/images/layers-368ccce4.png "Architecture Overview") 1212 | 1213 | 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. 1214 | 1215 | 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. 1216 | 1217 | 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`](https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing) olarak bilinen bir teknik kullanır; bu 5 parçadan 3'ü ana anahtarın yeniden yapılandırılması için gereklidir. 1218 | 1219 | ![Keys](https://www.vaultproject.io/assets/images/keys-468a5903.png "Keys") 1220 | 1221 | 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. 1222 | 1223 | 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. 1224 | 1225 | 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. 1226 | 1227 | 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. 1228 | 1229 | 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. 1230 | 1231 | 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. 1232 | 1233 | 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. 1234 | 1235 | 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. 1236 | 1237 | #### Derinlemesine Bakış 1238 | 1239 | Az önce Vault mimarisine kısa bir genel bakış yaptık. Sistemlerin her biri için daha ayrıntılı konuşabiliriz. 1240 | 1241 | Diğer ayrıntılar için, kaynak kodu inceleyebilir, IRC'ye sorabilir veya posta listesine ulaşabilirsiniz. 1242 | 1243 | ### Yüksek Servis Sürekliliği 1244 | 1245 | 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. 1246 | 1247 | > 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. 1248 | 1249 | 1250 | #### Tasarıma Genel Bakış 1251 | 1252 | 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. 1253 | 1254 | 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. 1255 | 1256 | 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. 1257 | 1258 | 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. 1259 | 1260 | 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. 1261 | 1262 | ### Güvenlik Modeli 1263 | 1264 | 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. 1265 | 1266 | 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. 1267 | 1268 | --------------------------------------------------------------------------------