All doc about vault - singhakanksha/expVault GitHub Wiki
VAULT
A tool for securely accessing secrets
The key features of Vault are:
Secure Secret Storage: Arbitrary key/value secrets can be stored in Vault. Vault encrypts these secrets prior to writing them to persistent storage, so gaining access to the raw storage isn't enough to access your secrets. Vault can write to disk, Consul, and more.
Dynamic Secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.
Data Encryption: Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.
Leasing and Renewal: All secrets in Vault have a lease associated with them. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
Revocation: Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.
Use Cases
Before understanding use cases, it's useful to know what Vault is. This page lists some concrete use cases for Vault, but the possible use cases are much broader than what we cover.
General Secret Storage
At a bare minimum, Vault can be used for the storage of any secrets. For example, Vault would be a fantastic way to store sensitive environment variables, database credentials, API keys, etc.
Compare this with the current way to store these which might be plaintext in files, configuration management, a database, etc. It would be much safer to query these using vault read or the API. This protects the plaintext version of these secrets as well as records access in the Vault audit log.
Employee Credential Storage
While this overlaps with "General Secret Storage", Vault is a good mechanism for storing credentials that employees share to access web services. The audit log mechanism lets you know what secrets an employee accessed and when an employee leaves, it is easier to roll keys and understand which keys have and haven't been rolled.
API Key Generation for Scripts
The "dynamic secrets" feature of Vault is ideal for scripts: an AWS access key can be generated for the duration of a script, then revoked. The keypair will not exist before or after the script runs, and the creation of the keys are completely logged.
This is an improvement over using something like Amazon IAM but still effectively hardcoding limited-access access tokens in various places.
Data Encryption
In addition to being able to store secrets, Vault can be used to encrypt/decrypt data that is stored elsewhere. The primary use of this is to allow applications to encrypt their data while still storing it in the primary data store.
The benefit of this is that developers do not need to worry about how to properly encrypt data. The responsibility of encryption is on Vault and the security team managing it, and developers just encrypt/decrypt data as needed.
INSTALL
https://www.vaultproject.io/downloads.html
CMI-DT198:~ asingh$ /Users/asingh/Downloads/vault -version
output : CMI-DT198:~ asingh$ /Users/asingh/Downloads/vault -version Vault v0.6.5 ('5d8d702f33b5fd965cbe8d6d0728295de813a196')
RUN******
Starting the Dev Server
First, we're going to start a Vault dev server. The dev server is a built-in, pre-configured server that is not very secure but useful for playing with Vault locally. Later in this guide we'll configure and start a real server.
To start the Vault dev server, run:
$ vault server -dev
output : CMI-DT198:~ asingh$ /Users/asingh/Downloads/vault server -dev ==> Vault server configuration:
Backend: inmem
Cgo: disabled
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "", tls: "disabled")
Log Level: info
Mlock: supported: false, enabled: false
Version: Vault v0.6.5
Version Sha: 5d8d702f33b5fd965cbe8d6d0728295de813a196
==> WARNING: Dev mode is enabled!
In this mode, Vault is completely in-memory and unsealed. Vault is configured to only have a single unseal key. The root token has already been authenticated with the CLI, so you can immediately begin using the Vault CLI.
The only step you need to take is to set the following environment variables:
export VAULT_ADDR='http://127.0.0.1:8200'
The unseal key and root token are reproduced below in case you want to seal/unseal the Vault or play with authentication.
Unseal Key: 7pv7O8P/3E08pk/WWlkpdPpZeyqfgoA+KIa7Gvkk5bs= Root Token: 6a532d30-d3a6-6375-193a-a12af3c46773
==> Vault server started! Log data will stream in below:
2017/02/22 15:18:14.430293 [INFO ] core: security barrier not initialized 2017/02/22 15:18:14.430494 [INFO ] core: security barrier initialized: shares=1 threshold=1 2017/02/22 15:18:14.430597 [INFO ] core: post-unseal setup starting 2017/02/22 15:18:14.442074 [INFO ] core: loaded wrapping token key 2017/02/22 15:18:14.442430 [INFO ] core: successfully mounted backend: type=generic path=secret/ 2017/02/22 15:18:14.442449 [INFO ] core: successfully mounted backend: type=cubbyhole path=cubbyhole/ 2017/02/22 15:18:14.442549 [INFO ] core: successfully mounted backend: type=system path=sys/ 2017/02/22 15:18:14.442620 [INFO ] rollback: starting rollback manager 2017/02/22 15:18:14.443100 [INFO ] expiration: restoring leases 2017/02/22 15:18:14.443132 [INFO ] core: post-unseal setup complete 2017/02/22 15:18:14.443227 [INFO ] core: root token generated 2017/02/22 15:18:14.443229 [INFO ] core: pre-seal teardown starting 2017/02/22 15:18:14.443252 [INFO ] rollback: stopping rollback manager 2017/02/22 15:18:14.443260 [INFO ] core: pre-seal teardown complete 2017/02/22 15:18:14.443313 [INFO ] core: vault is unsealed 2017/02/22 15:18:14.443323 [INFO ] core: post-unseal setup starting 2017/02/22 15:18:14.443341 [INFO ] core: loaded wrapping token key 2017/02/22 15:18:14.443727 [INFO ] core: successfully mounted backend: type=generic path=secret/ 2017/02/22 15:18:14.443754 [INFO ] core: successfully mounted backend: type=cubbyhole path=cubbyhole/ 2017/02/22 15:18:14.443923 [INFO ] core: successfully mounted backend: type=system path=sys/ 2017/02/22 15:18:14.443962 [INFO ] rollback: starting rollback manager 2017/02/22 15:18:14.444310 [INFO ] expiration: restoring leases 2017/02/22 15:18:14.444325 [INFO ] core: post-unseal setup complete
With the dev server running, do the following three things before anything else:
Launch a new terminal session.
Copy and run the export VAULT_ADDR ... command from the terminal output. This will configure the Vault client to talk to our dev server.
Save the unseal key somewhere. Don't worry about how to save this securely. For now, just save it anywhere.
Do the same as step 3, but with the root token. We'll use this later.
we are about to use vault CLI to explain READ/WRITE operation but there is an api as well below is the link. COME BACK :::::: https://www.vaultproject.io/docs/http/
impo::::::: Secrets written to Vault are encrypted and then written to backend storage. For our dev server, backend storage is in-memory, but in production this would more likely be on disk or in Consul. Vault encrypts the value before it is ever handed to the storage driver. The backend storage mechanism never sees the unencrypted value and doesn't have the means necessary to decrypt it without Vault.
VAULT WRITE DOCUMENTATION
https://www.vaultproject.io/docs/commands/read-write.html
CMI-DT198:~ asingh$ ~/Downloads/vault write secret/password \
value=itsasecret Success! Data written to: secret/password
VAULT READ
CMI-DT198:~ asingh$ ~/Downloads/\vault read -format=json secret/hello { "request_id": "e8fa4fbe-1b6c-cfdd-0f77-e40e06f345ec", "lease_id": "", "lease_duration": 2764800, "renewable": false, "data": { "value": "world" }, "warnings": null }
SECRET BACKENDS VAULT MOUNTS
CMI-DT198:~ asingh$ ~/Downloads/vault mounts Path Type Default TTL Max TTL Description cubbyhole/ cubbyhole n/a n/a per-token private secret storage secret/ generic system system generic secret storage sys/ system n/a n/a system endpoints used for control, policy and debugging
CMI-DT198:~ asingh$ ~/Downloads/vault mount generic Successfully mounted 'generic' at 'generic'!
CMI-DT198:~ asingh$ ~/Downloads/vault mounts
Path Type Default TTL Max TTL Description
cubbyhole/ cubbyhole n/a n/a per-token private secret storage
generic/ generic system system
secret/ generic system system generic secret storage
sys/ system n/a n/a system endpoints used for control, policy and debugging
CMI-DT198:~ asingh$ ~/Downloads/vault write secret/password value=itsasecret Success! Data written to: secret/password
CMI-DT198:~ asingh$ ~/Downloads/vault write generic/password value=itsThesecret Success! Data written to: generic/password
CMI-DT198:~ asingh$ ~/Downloads/vault read secret/password Key Value
refresh_interval 768h0m0s value itsasecret
CMI-DT198:~ asingh$ ~/Downloads/vault read generic/password Key Value
refresh_interval 768h0m0s value itsThesecret
CMI-DT198:~ asingh$ /Downloads/vault unmount generic/
Successfully unmounted 'generic/' if it was mounted
CMI-DT198: asingh$ ~/Downloads/vault mounts
Path Type Default TTL Max TTL Description
cubbyhole/ cubbyhole n/a n/a per-token private secret storage
secret/ generic system system generic secret storage
sys/ system n/a n/a system endpoints used for control, policy and debugging
Dynamic Secrets