{"id":755,"date":"2018-07-14T10:27:10","date_gmt":"2018-07-14T10:27:10","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=755"},"modified":"2018-07-14T10:27:10","modified_gmt":"2018-07-14T10:27:10","slug":"setup-hashicorp-vault-beginners-guide","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=755","title":{"rendered":"How to Setup and Configure Hashicorp Vault Server – Detailed Beginners Guide"},"content":{"rendered":"

This Hashicorp vault beginners tutorial will walk you through the steps on how to setup and configure a Hashicorp vault server with detailed instructions.<\/p>\n

Introduction<\/h3>\n

Vault is a tool from HashiCorp<\/a> for securely storing and accessing secrets. Secret is nothing but all credentials like API Keys, passwords and certificates. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log. Most of the organizations would keep their secrets in GitHub which can be seen by anyone who has access to the repo. Vault is designed in such a way that we can keep our database credentials, API keys for external services, credentials into vault and access directly from the application using APIs using various authentication mechanisms. HashiCorp Vault has more advantages than other similar services like HSMs, AWS KM, and keywhiz.<\/p>\n

Most Common Use Cases of Vault<\/h2>\n

Following are the common use cases for Vault<\/p>\n

    \n
  1. A bare minimum vault can be used as a general secret storage, It is a great tool to store environment variables, DB credentials and API keys.<\/li>\n
  2. Vault is a good fit 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.<\/li>\n
  3. The “dynamic secrets” feature of Vault is ideal for scripts: It can generate an access key for the duration of a script runtime which is like temporary access token.<\/li>\n
  4. 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 being in the primary data store.<\/li>\n<\/ol>\n

    Key Vault Features<\/h2>\n

    Secure Secret Storage:<\/strong> Arbitrary key\/value secrets can be stored in Vault. It encrypts the secret and stores in a persistent backend storage. Vault supports multiple storage backends such as a local disk, consul<\/a> or cloud storage like AWS S3<\/a> or GCS bucket<\/a>.<\/p>\n

    Dynamic Secrets:<\/strong> 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.<\/p>\n

    Data Encryption:<\/strong> Vault is capable of encrypting and decrypting 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.<\/p>\n

    Leasing and Renewal:<\/strong> Secrets in vaults are associated with the lease, end of the lease vault will revoke the secrets, We can renew lease using renew APIs.<\/p>\n

    Revocation:<\/strong> Vault has built-in support for secret revocation.<\/p>\n

    Setup and configure Vault Server on Linux<\/h2>\n

    Follow the steps given below for setting up the vault server.<\/p>\n

    Step 1: <\/strong> Download the latest version of vault binary zip file from vault release page<\/a> and unzip it.<\/p>\n

    cd \/opt\/\nsudo wget https:\/\/releases.hashicorp.com\/vault\/0.10.3\/vault_0.10.3_linux_amd64.zip\nsudo unzip vault_0.10.3_linux_amd64.zip -d .<\/code><\/pre>\n
    Step 2:<\/strong> Copy vault binary into \/usr\/bin. This will allow us to execute vault binary systemwide.<\/p>\n
    sudo cp vault \/usr\/bin\/<\/code><\/pre>\n
    Step 3: <\/strong> Create a vault config directory under \/etc,  a vault data directory and logs directory.<\/p>\n
    sudo mkdir \/etc\/vault\nsudo mkdir \/vault-data\nsudo mkdir -p \/logs\/vault\/<\/code><\/pre>\n
    Step 4:<\/strong> Create a config.json file and add the vault configuration.<\/p>\n
    sudo vi \/etc\/vault\/config.json<\/code><\/pre>\n
    Add the below configuration to the file. Vault supports both JSON and HCL formats. Here we are using JSON format.<\/p>\n
    Note:<\/em><\/strong> replace 10.128.0.2 with your vault host public\/private IP.<\/p>\n
    {\n\"listener\": [{\n\"tcp\": {\n\"address\" : \"0.0.0.0:8200\",\n\"tls_disable\" : 1\n}\n}],\n\"api_addr\": \"http:\/\/10.128.0.2:8200\",\n\"storage\": {\n    \"file\": {\n    \"path\" : \"\/vault-data\"\n    }\n },\n\"max_lease_ttl\": \"10h\",\n\"default_lease_ttl\": \"10h\",\n\"ui\":true\n}<\/code><\/pre>\n
    max_lease_ttl<\/strong> – Specifies the maximum possible lease duration for tokens and secrets. This is specified using a label suffix like “30s” or “1h”.<\/p>\n
    default_lease_ttl<\/strong> – Specifies the default lease duration for tokens and secrets. This is specified using a label suffix like “30s” or “1h”. This value cannot be larger than max_lease_ttl.<\/p>\n
    Note<\/strong>:<\/em> This config file is created specifically to use filesystem backend, You can even use consul cluster<\/a> backend, S3 or GCS (Google cloud storage) backend like shown below,<\/p>\n
    Vault Consul Backend Config<\/strong><\/p>\n
    \"storage\": {\n   \"consul\" : {\n      \"address\" : \"127.0.0.1:8500\",\n      \"path\": \"vault\"\n    }\n }<\/code><\/pre>\n
    Vault Google Storage (GCS) Backend Config<\/strong><\/p>\n
    \"storage\": {\n\"gcs\": {\n\"bucket\" : \u201cdevopscube-demo\",\n\"ha_enabled\" : \"true\"\n}\n}<\/code><\/pre>\n
    Step 5:<\/strong> Create a vault service file.<\/p>\n
    sudo vi \/etc\/systemd\/system\/vault.service<\/code><\/pre>\n
    Copy the following contents to the service file.<\/p>\n
    [Unit]\nDescription=vault service\nRequires=network-online.target\nAfter=network-online.target\nConditionFileNotEmpty=\/etc\/vault\/config.json\n\n[Service]\nEnvironmentFile=-\/etc\/sysconfig\/vault\nEnvironment=GOMAXPROCS=2\nRestart=on-failure\nExecStart=\/usr\/bin\/vault server -config=\/etc\/vault\/config.json\nStandardOutput=\/logs\/vault\/output.log\nStandardError=\/logs\/vault\/error.log\nLimitMEMLOCK=infinity\nExecReload=\/bin\/kill -HUP $MAINPID\nKillSignal=SIGTERM\n\n[Install]\nWantedBy=multi-user.target\n<\/code><\/pre>\n
    Step 6: <\/strong>Start the vault service.<\/p>\n
    sudo systemctl start vault.service<\/code><\/pre>\n
    Check the service status.<\/p>\n
    sudo systemctl status vault.service<\/code><\/pre>\n
    Enable vault service at boot up to make sure it starts automatically for reboots,<\/p>\n
    sudo systemctl enable vault.service<\/code><\/pre>\n
    Step 7:<\/strong> Login as root and Export VAULT_ADDR environment variable, don\u2019t forget to add this to ~\/.bashrc file. Change the IP to you vault server public\/private IP.<\/p>\n
    export VAULT_ADDR=http:\/\/10.128.0.2:8200\necho \"export VAULT_ADDR=http:\/\/10.128.0.2:8200\" >> ~\/.bashrc<\/code><\/pre>\n
    Step 8:<\/strong> Check the status using vault status<\/p>\n
    vault status<\/code><\/pre>\n
    You will get an error server is not yet initialized as shown below. You could see vault is sealed by default. This is because of the default behavior of vault.<\/p>\n
    Error checking seal status: Error making API request.\n\nURL: GET http:\/\/104.198.185.234:8200\/v1\/sys\/seal-status\nCode: 400. Errors:\n\n* server is not yet initialized<\/code><\/pre>\n
    Let’s initiate the vault server and store the initial tokens in a file.<\/p>\n
    Note<\/em><\/strong>: execute the following command by logging in as the root user.<\/p>\n
    vault operator init > \/etc\/vault\/init.file<\/code><\/pre>\n
    Noe vault is initiated but sealed. You can view the status using the following command.<\/p>\n
    vault status<\/code><\/pre>\n
    Open the init file to get the unseal and root tokens. These tokens can be used to unseal the vault web UI during the first login.<\/p>\n
    cat \/etc\/vault\/init.file<\/code><\/pre>\n
    An example, the output containing the root token is shown below.<\/p>\n
    Unseal Key 1: jsQ6ZshBCowoddwDhHTy7DgJU9To8YAprYToqPkMUrNg\nUnseal Key 2: 9PWznYV+uM+a1o6rMEGcuINeCtGnMRiV1a5xTe6EerSd\nUnseal Key 3: mavIFllXbQmo7QE2qmLuH9HfYEPQMLpCZNgT0QoRUkcE\nUnseal Key 4: VzXhuvnNuZkld4LnhPEjNyTEMJR3qIkq\/UsinwWWdv5l\nUnseal Key 5: ho23N6R2WGPOpijGsCMElv\/z4u9OxMw9AbEEMbePySU7\n\nInitial Root Token: d4dd0b96-4767-57a3-9081-aca03e530c8f\n\nVault initialized with 5 key shares and a key threshold of 3. Please securely\ndistribute the key shares printed above. When the Vault is re-sealed,\nrestarted, or stopped, you must supply at least 3 of these keys to unseal it\nbefore it can start servicing requests.\n\nVault does not store the generated master key. Without at least 3 key to\nreconstruct the master key, Vault will remain permanently sealed!\n\nIt is possible to generate new unseal keys, provided you have a quorum of\nexisting unseal keys shares. See \"vault operator rekey\" for more information.<\/code><\/pre>\n
    Once a Vault is unsealed, it remains unsealed until one of two things happens:<\/p>\n
      \n
    1. It is re-sealed via the API (see below).<\/li>\n
    2. If vault service gets restarted or during a server restart.<\/li>\n<\/ol>\n
      Step 9:<\/strong> Unseal vault using unseal command. There are 5 unseal tokens. You need to execute the unseal command with a minimum of three unseal token to unseal vault.<\/p>\n
      vault operator unseal jsQ6ZshBCowoddwDhHTy7DgJU9To8YAprYToqPkMUrNg\nvault operator unseal 9PWznYV+uM+a1o6rMEGcuINeCtGnMRiV1a5xTe6EerSd\nvault operator unseal mavIFllXbQmo7QE2qmLuH9HfYEPQMLpCZNgT0QoRUkcE<\/code><\/pre>\n
      Here you can see your standalone vault is up and running successfully, you can start by enabling authentication method and secret engine which you like,<\/p>\n
      [root@devopscube opt]# vault status\nKey Value\n--- -----\nSeal Type shamir\nSealed false\nTotal Shares 5\nThreshold 3\nVersion 0.10.3\nCluster Name vault-cluster-865eaf7d\nCluster ID 3164ab8f-d344-c835-af14-644cdc487a73\nHA Enabled true\nHA Cluster https:\/\/10.128.0.2:8201\nHA Mode active<\/code><\/pre>\n
      Step 10:<\/strong> Now you can also view vault console using the following URL,<\/p>\n
      http:\/\/IPADDRESS:8200\/ui<\/code><\/pre>\n
      Finally, you can log in with root credentials which we created while initializing vault, in our case d4dd0b96-4767-57a3-9081-aca03e530c8f. Managing will be easy through UI<\/p>\n
      Once you login you will see the following page,<\/p>\n
      \"vault<\/figure>\n
      Vault Roles and Policies<\/h3>\n
      Once the setup is done, you can use vault by enabling AppRoles or some other auth methods with proper policies associated with it. Covering full roles and policies is out of the scope of this article.<\/p>\n
      You can create AppRole and Policies through CLI as well as vault console.<\/p>\n
      vault auth enable approle\nvault write auth\/approle\/role\/demo bound_cidr_list=10.0.0.0\/16 bind_secret_id=false policies=default-policy<\/code><\/pre>\n
      Note:<\/em><\/strong> This same can be done from Vault console also<\/p>\n
      bound_cidr_list:<\/strong> If bound_cidr_list is set on the role, then the list of CIDR blocks listed here should be a subset of the CIDR blocks listed on the role.<\/p>\n
      bind_secret_id:<\/strong> Require secret_id to be presented when logging in using this AppRole.<\/p>\n
      Configure secrets from the console as shown in below image, by default vault uses KV secret engine, we can even use AWS, RabbitMQ, Google cloud or any databases as a secret engine.<\/p>\n
      \"hashicorp<\/figure>\n
      Vault server which we have created is a standalone instance with HA Enabled configuration, If we disable HA Enabled option from config.json this will act as a cluster without HA.<\/p>\n
      To enable HA we can have multiple machines where we configure api_addr parameter as the host IP, at a time only one of the node will act as the active node and rest of them are standby nodes.<\/p>\n
      \n
      ONLINE COURSE: <\/strong>Managing Secrets with Hashicorp Vault<\/p>\n
      \"hashicorp<\/figure>\n
      Everything you need to get started with Hashicorp Vault<\/p>\n
      Managing Secrets with Hashicorp Vault<\/a><\/p>\n