The Vault provides a secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API.
Download current Windows binary from: https://www.vaultproject.io/downloads.html
The binary can be located in any desired folder directory. For this instance on a computer named, computer1, the Hashicorp Vault binary is located in the folder, C:\bin\Vault.
Add the Vault installation folder to the system path environmental variable.
The following is just documenting how the Hashicorp Vault server could be setup on standalone Windows 10 or server computer named, computer1. For the full details and concepts please see the official documentation at: https://www.vaultproject.io/docs/install/index.html
The starting of the Hashicorp Vault server expects a configuration to be specified that communicates the TCP listener and storage parameters for the vault server. computer1's configuration file is located in the folder, C:\bin\Vault\vault.computer1.hcl. The contents of the file is:
storage "file" {
path="C:/MS-Vault"
}
listener "tcp" {
address = "computer1:8200"
cluster_address = "computer1:8201"
tls_disable = 0
tls_cert_file = "C:/bin/Vault/vault-computer1-ssl.crt"
tls_key_file = "C:/bin/Vault/vault-computer1-ssl.key"
}
api_addr = "https://computer1:8200"
ui = true
For this implementation, I want the Vault storage to be located in the folder, C:\MS-Vault.
The HTTPS protocol is going to be used for this implementation, so the api_addr was set accordingly. computer1 is not part of a Windows domain nor does it have a static IP address allocated to it. So on my router, I configured a DHCP reserved IP address for computer1. I then added the entry '192.168.1.125 computer1' to the file, C:\Windows\System32\drivers\etc\hosts file so the name lookup will resolve.
The self-signed certificate referenced in the configuration will be created using OpenSSL. OpenSSL can be downloaded from https://slproweb.com/products/Win32OpenSSL.html.
Install OpenSSL in the folder C:\bin\OpenSSL-Win64
Add the OpenSSL installation folder to the system path environmental variable.
openssl.exe req -x509 -batch -nodes -newkey rsa:2048 -keyout vault-computer1-ssl.key -out vault-computer1-ssl.crt -days 1825 `
-subj "/C=US/ST=WA/L=Bow/O=KillRoy/OU=SE/CN=computer1"
This will create a Private key (.key) and a CSR (Self-Signed Certificate ) code (.crt) files. Copy output files to C:\bin\vault on computer1.
On computer1 start a PowerShell session as admin and execute the following command.
Import-Certificate -filePath vault-computer1-ssl.crt -CertStoreLocation "cert:\LocalMachine\Root"
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint Subject
---------- -------
2B5115A324A6C766592D1663C89D1D4224EA1B5F CN=computer1, OU=SE, O=KillRoy, L=Bow, S=WA, C=US
Certificated is now imported to the local machine certificate store.
Verify certificate exists in the Trusted Root Certification folder. Run 'certlm.msc'. A certificate named computer1 should be present.
The Vault server on computer1 will be configured to run as a service by using the Non-Sucking Service Manager (nssm) downloaded from https://nssm.cc/usage.
nssm status vault
S E R V I C E _ R U N N I N G
nssm stop vault
nssm start vault
Upon starting the Vault server for the first time, the vault's storage location specified in the configuration file must be initialized.
The CLI will be used the first time to start the Vault Server, but there after the Vault server will run as a Service.
The CLI command for starting the vault server is:
vault server -config "C:\bin\Vault\vault.computer1.hcl"
WARNING! mlock is not supported on this system! An mlockall(2)-like syscall to
prevent memory from being swapped to disk is not supported on this system. For
better security, only run Vault on systems where this call is supported. If
you are running Vault in a Docker container, provide the IPC_LOCK cap to the
container.
==> Vault server configuration:
Api Address: https://computer1:8200
Cgo: disabled
Cluster Address: https://computer1:8201
Listener 1: tcp (addr: "computer1:8200", cluster address: "computer1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
Log Level: info
Mlock: supported: false, enabled: false
Recovery Mode: false
Storage: file
Version: Vault v1.3.0
==> Vault server started! Log data will stream in below:
2019-12-12T20:51:59.128-0800 [INFO] proxy environment: http_proxy= https_proxy= no_proxy=
Given the TCP parameters specified in the configuration file, the URL for Vault Web UI is:
https://computer1:8200/
Navigate to the above URL and the Web interface will guide you through the Vault initialization. For this installation, 5 Key shares was requested and specified that 3 of those key shares are required to reconstruct the master key. There is an option on the initialization page to download the generate keys in a JSON file.
Later instructions will be provided a method on how to this JSON file.
Every Vault server initially starts as sealed. It cannot perform any operation except unsealing until it is unsealed. Secrets cannot be accessed in any way until the vault is unsealed. The Web UI will prompt for the 3 of the 5 keys to unseal the Vault.
root token: #######################################
key 1: ############################################
key 2: ############################################
key 3: ############################################
key 4: ############################################
key 5: ############################################
The root token needs to be used the first time to log into the Web UI to enable any one of many different authentication methods. After the initial vault server step is completed, the root token should not be used again to authenticate to the vault server. Following this practice reduces the risk of the root token being comprimized. Open the downloaded JSON file and copy the root token to log into the Vault Server Web interface.
On the initial log into Web UI with the root token, User access method(s) need to be created and any desired Policies need to be defined. Policies will be defined first because users defined to have access the Vault server will reference a specific policy.
Everything in Vault is path based, and policies are no exception. Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault. Accounts logging into Vault reference a named Policy that defines access rights for the account. Logging in with the root token provides access without any restrictions. There is a default policy that all acounts reference but provide very limited access.
Two access policies, admin and shared will be defined by importing a HCL file from the Web UI. The admin policy will be the path for non-shared secrets and will be 2nd level administrators for the Vault and shared policy will be for all other accounts accessing secrets.
From the Web UI login with the root token and select the Policies tab. Then click on the link Create ACL policy + in the upper right hand corner. On the Create ACL Policy enter a policy name, admin and click on the Upload file switch. The following HCL file was uploaded for the admin policy.
path "admin/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "admin/data/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "shared/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "shared/data/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
Accounts assigned to the admin Policy have full rights to both paths admin and shared.
The shared policy was defined by uploading the following HCL file.
path "shared/*" {
capabilities = ["read", "list"]
}
path "shared/data/*" {
capabilities = ["read", "list"]
}
Accounts assigned to the shared Policy have read and list rights to only the shared path.
An account needs to be created to provide authorization to access the Vault server. There are many different authorization methods supported.
From the Web UI, select the Access tab then click on the Enable new method + link toward the upper right of the Web UI. Now select Username & Password method and define an account and password for logging into the Vault server. The account defined should reference either the admin and/or Shared access policy.
Enable the kv secret engine by clicking on Secrets and then clicking on the Enable new engine + link.
Enable KV secret paths cooresponding to the Policies, admin and shared created above. We'll use the Vault CLI to create the paths.
The Vault CLI uses the environmental variable VAULT_ADDR to determine Vault server interface.
$env:VAULT_ADDR="https://computer1:8200"
Logging in with the root token.
vault login -method=token <root_token>
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
Key Value
--- -----
token ##################################
token_accessor ########################
token_duration ∞
token_renewable false
token_policies ["root"]
identity_policies []
policies ["root"]
From the output above, one can see that we are logged in using the root token. Lets enable the KV paths supporting the admin and shared policies.Z
vault secrets enable -path=admin kv
Success! Enabled the kv secrets engine at: admin/
vault secrets enable -path=shared kv
Success! Enabled the kv secrets engine at: shared/
With this configuration in place the authorized accounts created above should now be able to create and/or retrieve KV secrets based on the access policy associated with the account.
If desired, auditing of the Vault server can be enabled.
vault audit enable file file_path="C:/bin/vault/vault.log" Success! Enabled the file audit device at: file/
Enter the following Vault CLI command to disable auditing.
vault audit disable file
If logged into the Web UI with the root token, logout. Now log into the Web UI using the one of the accounts created above.
With the KV Secret Engine enabled, lets validate a given account can create and retrieve KV secrets using the Vault CLI commands.
When logged in with the account that is associated to the admin policy, both the admin and shared paths should be displayed. Plus you should be able to create KV secrets in both of these paths.
When logged in with the account that is associated to the shared policy, only the shared path should be displayed. This account is also limited to only listing or reading KV secrets in the shared path.
For this exercise, 'test' was created in the admin path with a key and value pairing of test1=test1 and 'test' was create in the shared path with a key and value pairing of test2=test2.
The Vault CLI uses the environmental variable VAULT_ADDR to determine Vault server interface.
$env:VAULT_ADDR="https://computer1:8200"
The Vault CLI can also be used to test the KV secret engine.
Logging in with the account associated with the admin policy.
vault login -method=userpass username=KillRoy Output: Password (will be hidden): Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token ################################## token_accessor ########################### token_duration 30m token_renewable true token_policies ["admin" "default"] identity_policies [] policies ["admin" "default"] token_meta_username KillRoy
From the output above, one can see the account is associated with both the admin and default policies. These policies control what the account has authorization to do.
vault token capabilities admin/ create, delete, list, read, update
vault token capabilities shared/ create, delete, list, read, update
From the above, the account has full authorization to the paths admin and shared as determined by the policies.
vault kv list admin Output: Keys ---- test
Repeat the same command but for the shared path.
vault kv put admin/myapp mysecret=mybigsecret Success! Data written to: admin/myapp
Now login into the Vault Web UI with the account and review the entry.
vault kv get admin/myapp Output: ====== Data ====== Key Value --- ----- mysecret mybigsecret
It is important to remember that the Vault login authorization is only valid for a specific amount of time. When that time runs out, the account must login again to establish authorization.
If you are seeing unexpected permission denied errors, it is likely your account authorization has expired.
Hashicorp supports many different client libraries for accessing the Vault server's RestAPI. See https://www.vaultproject.io/api/libraries.html for a full listing of the client libraries.
The icing on the cake for PowerShell coders is the Zyborg.Vault module. Now, interacting with the Vault server can be a fully automated experience.
This PowerShell module is very comprehensive and supports almost all of the Vault CLI commands. Below are some examples of using the Zyborg.Vault cmdlets used to access a Vault server.
Install-Module Zyborg.Vault
# Get Authorization to access the Vault server $env:VAULT_ADDR="https://computer1:8200" $creds = Get-Credential -Message "Enter Vault Credentials" $x1 = New-VltAuth -AuthMethod userpass -PathData $creds.Username -AuthData @{ password = $creds.GetNetworkCredential().Password } -va $env:VAULT_ADDR # Get the client token for accessing the Vault server RestAPI $ct = $x1.ClientToken; # Verify the client token is valid Test-VltInstance -VaultToken $ct -va $env:VAULT_ADDR True # Get the credentials from the Vault server for accessing myapp $x2 = Read-VltData -Path admin/myapp -vt $ct -va $env:VAULT_ADDR PS>$x2 Key Value --- ----- mysecret mybigsecret
The CLI command for starting the vault server is:
vault server -config "C:\bin\Vault\vault.computer1.hcl"
Every Vault server initially starts as sealed. It cannot perform any operation except unsealing until it is unsealed. Secrets cannot be accessed in any way until the vault is unsealed.
if ($(Get-VltStatus).Sealed) { $keys = @("key1","key2","key3") Unlock-VltServer -key $keys -va $env:VAULT_ADDR | Out-Null }
Lock-VltServer -va $env:VAULT_ADDR -vt <root_token> | Out-Null (Get-VltStatus).Sealed
With the Vault server functioning as expected, it time to enable the Vault server as a Windows service so it is automately ran with the computer is started.
The Non-Sucking Service Manager (NSSM) was downloaded from https://nssm.cc/usage to run the Vault Server executable as a Windows Service.
The service name will be called Vault and can be controlled using either the normal Windows Service management interface or using the CLI provide by NSSM. To initially configure the server and modify the service, the NSSM CLI must be used.
Start a PowerShell session or CMD session with admin privileges.
nssm install vault
Completing the appropriate NSSM dialogs should not require any specific instructions. If instructions are needed, see the NSSM web site.
This worked perfectly for me on a Windows 2016 server. On Windows 10 (1809), the service crashes shortly after starting and the event log entry still leaves one clueless.
All of the above is meant to be a very basic introducation into setting up an using Hashicorp Vault server on a standalone computer. To gain a full understanding of all the capabilities of a Hashicorp Vault server review the offical documentation. https://www.vaultproject.io/docs/index.html