Vault
HomeDocumentationTutorialsTry Cloud!
  • Vault
  • Documentation
    • What is Vault?
    • Use Cases
    • Setup
      • Install
      • Configuration
    • Get Started
      • Starting the server
      • Your first secret
      • Deploying Vault on VMs with Let's encrypt! TLS certs
    • Concepts
      • Operations
        • Seal/Unseal
        • "Dev" server mode
        • Namespace lock and unlock
        • Lease, renew, and revoke
        • Lease Explosions
        • Mount migration
        • Client count
        • Resource quotas
        • Response wrapping
      • Authentication
        • Identity
        • Tokens
        • OIDC provider
        • Username templating
        • Passwordless
      • Secrets
      • Storage
        • Integrated storage
        • High availability mode (HA)
        • Recovery mode
      • Policies
  • Tutorials
    • CLI
      • Operations
        • Deploy Vault
        • Using the HTTP API
        • Unseal/Seal
      • Authentication
        • Token
        • GitHub authentication
        • Username/Password
        • TLS Client Certificates
        • SSH Keys
        • AWS, Azure, GCP and external auth methods
          • Azure
          • AWS
          • GCP
          • Github
          • Terraform
      • Secrets
        • Secrets engines
        • Built-in help
      • Access Control
        • Policies
    • UI
      • Authentication
        • Username/Password
        • Passwordless
      • Operations
        • Unseal / Seal
        • API Explorer
      • Secrets
        • Secrets engines
      • Access Control
        • Policies
    • Use Cases
      • Namespaces
      • MongoDB admin password
      • VM Disk Encryption Keys
      • VM SSH Keys
      • Kubernetes Configuration
      • GitHub Actions
      • Dynamic credentials for cloud providers
        • AWS
        • Azure
        • GCP
  • CLI
    • agent
    • audit
    • auth
    • debug
    • delete
    • events
    • kv
    • lease
    • license
    • list
    • login
    • monitor
    • namespace
    • operator
    • patch
    • path-help
    • pki
    • plugin
    • policy
    • print
    • proxy
    • read
    • secrets
    • server
    • ssh
    • status
    • token
    • transit
    • unwrap
    • version
    • version-history
    • write
  • API
    • Secrets engines
      • AliCloud secrets engine (API)
      • AWS secrets engine (API)
      • Azure secrets engine (API)
      • Cubbyhole secrets engine (API)
      • Database
        • Cassandra database plugin HTTP API
        • Elasticsearch database plugin HTTP API
        • Influxdb database plugin HTTP API
        • MongoDB database plugin HTTP API
        • MSSQL database plugin HTTP API
        • MySQL/MariaDB database plugin HTTP API
        • Oracle database plugin HTTP API
        • PostgreSQL database plugin HTTP API
        • Redis database plugin HTTP API
        • Redis ElastiCache database plugin HTTP API
        • Redshift database plugin HTTP API
        • Snowflake database plugin HTTP API
      • Google Cloud secrets engine (API)
      • Google Cloud KMS secrets engine (API)
      • Identity
        • entity
        • entity-alias
        • group
        • group-alias
        • tokens
        • lookup
        • oidc-provider
        • MFA
          • duo
          • okta
          • pingid
          • totp
          • login-enforcement
      • KV secrets engine (API)
      • Buckypaper secrets engine
      • Kubernetes secrets engine (API)
      • Nomad secrets engine (API)
      • LDAP secrets engine (API)
      • PKI secrets engine (API)
      • RabbitMQ secrets engine (API)
      • SSH secrets engine (API)
      • TOTP secrets engine (API)
      • Transit secrets engine (API)
    • Auth engines
      • AliCloud auth method (API)
      • AppRole auth method (API)
      • AWS auth method (API)
      • Azure auth method (API)
      • Pivotal Cloud Foundry (CF) auth method (API)
      • GitHub auth method (API)
      • Google Cloud auth method (API)
      • JWT/OIDC auth method (API)
      • Kerberos auth method (API)
      • Kubernetes auth method (API)
      • LDAP auth method (API)
      • OCI auth method (API)
      • Okta auth method (API)
      • Passwordless auth method (API)
      • RADIUS auth method (API)
      • TLS certificate auth method (API)
      • Token auth method (API)
      • Userpass auth method (HTTP API)
    • Service engines
      • Licence Manager
    • System backend
      • /sys/audit
      • /sys/audit-hash
      • /sys/auth
      • /sys/capabilities
      • /sys/capabilities-accessor
      • /sys/capabilities-self
      • /sys/config/auditing/request-headers
      • /sys/config/control-group
      • /sys/config/cors
      • /sys/config/reload
      • /sys/config/state
      • /sys/config/ui
      • /sys/decode-token
      • /sys/experiments
      • /sys/generate-recovery-token
      • /sys/generate-root
      • /sys/health
      • /sys/host-info
      • /sys/in-flight-req
      • /sys/init
      • /sys/internal/counters
      • /sys/internal/inspect
        • /sys/internal/inspect/router
      • /sys/internal/specs/openapi
      • /sys/internal/ui/feature-flags
      • /sys/internal/ui/mounts
      • /sys/internal/ui/namespaces
      • /sys/internal/ui/resultant-acl
      • /sys/key-status
      • /sys/ha-status
      • /sys/leader
      • /sys/leases
      • /sys/license/status
      • /sys/locked-users
      • /sys/loggers
      • /sys/metrics
      • /sys/monitor
      • /sys/mounts
      • /sys/namespaces
      • /sys/plugins/reload/backend
      • /sys/plugins/catalog
      • /sys/plugins/runtimes/catalog
      • /sys/policy
      • /sys/policies/
      • /sys/policies/password/
      • /sys/pprof
      • /sys/quotas/config
      • /sys/quotas/rate-limit
      • /sys/quotas/lease-count
      • /sys/raw
      • /sys/rekey
      • /sys/rekey-recovery-key
      • /sys/remount
      • /sys/rotate
      • /sys/rotate/config
      • /sys/seal
      • /sys/seal-status
      • /sys/seal-backend-status
      • /sys/step-down
      • /sys/storage
        • /sys/storage/raft
        • /sys/storage/raft/autopilot
      • /sys/tools
      • /sys/unseal
      • /sys/version-history
      • /sys/wrapping/lookup
      • /sys/wrapping/rewrap
      • /sys/wrapping/unwrap
      • /sys/wrapping/wrap
  • Resources
    • Blog
    • GitHub
    • Youtube
    • CCx101
Powered by GitBook
On this page
  • Approle
  • Policy
  • Vaultlocker
  • Run
  • Setting up the service file
  1. Tutorials
  2. Use Cases

VM Disk Encryption Keys

In this article, we'll guide you through the process of preparing Vault for storing our LUKS keys and obtaining the necessary details to integrate hosts with Vault. Additionally, we'll aim to conclude by setting up a client to test the entire system. To facilitate this, you should have set up a new VM and added an additional disk to it within a cluster.

Approle

To begin, we'll create a new backend on Vault using Approles instead of the KV store. Approles are particularly useful for machine or service authentication rather than human users.

Normally, we'd require the approle_id and the secret_id to obtain a valid token from Vault. However, in our current setup, only the approle and being within the specified CIDR range are necessary. Here's the command used:

vault write auth/approle/role/vaultlocker bound_cidr_list=192.168.0.0/24 token_bound_cidrs=192.168.0.0/24 policies=vaultlocker

This command creates an approle named "vaultlocker" with the associated policy "vaultlocker" (which we'll create shortly) and restricts access to my internal network.

Next, we need to create the policy.

Policy

We need to define a policy for this approle. Here's the policy:

path "/vaultlocker/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

After creating the policy, rerun the approle creation command.

That should cover the necessary configurations.

Vaultlocker

The script we're utilizing, called Vault Locker, appears to be part of the OpenStack suite. It's a relatively small Python script but seems to function effectively.

Installation

Installation is straightforward; you can install the vaultlocker using pip.

pip install vaultlocker

Additionally, you'll need to create the config directory and file:

mkdir /etc/vaultlocker
touch /etc/vaultlocker/vaultlocker.conf

Vaultlocker.conf

Configuration for vaultlocker is stored in /etc/vaultlocker/vaultlocker.conf. It's a simple file containing three key pieces of information. Here's a sample configuration with the IDs omitted:

[vault]
url = http://vault.xxx.host
approle = qqqqq-wwww-eeee-rrr-ttt-yyyy
secret_id = yyy-ttt-rrr-eee-wwww
backend = /vaultlocker

You can retrieve your approle ID using the following command:

vault read auth/approle/role/vaultlocker/role-id

which will output the approle ID.

[jon@jons-laptop ~]$ vault read auth/approle/role/vaultlocker/role-id
Key        Value
---        -----
role_id    qqqqq-wwww-eeee-rrr-ttt-yyyy

If you've used the provided command to create the approle, the secret ID isn't necessary.

The backend refers to the path where data is stored.

Run

Let's put our setup to the test.

Firstly, we need to gather some information about the disk we intend to encrypt, ideally its UUID. For testing, here we'll be using /dev/sdb1. You can check in /dev/disk/by-uuid to find the UUID of your disk:

[root@test ~]# ls -lash /dev/disk/by-uuid/
total 0
0 drwxr-xr-x. 2 root root 140 Nov 10 03:53 .
0 drwxr-xr-x. 6 root root 120 Nov 10 03:53 ..
0 lrwxrwxrwx. 1 root root  10 Nov 10 03:53 09a0896e-6e60-47d8-a51c-a538b94db494 -> ../../sda1
0 lrwxrwxrwx. 1 root root   9 Nov 10 03:53 2019-09-11-18-50-31-00 -> ../../sr0
0 lrwxrwxrwx. 1 root root  10 Nov 10 03:53 65242782-090c-44ab-8808-289b5903a6a6 -> ../../sdb1
0 lrwxrwxrwx. 1 root root  10 Nov 10 03:53 e45b5102-c583-4b96-805b-b52a4c440ce4 -> ../../dm-0
0 lrwxrwxrwx. 1 root root  10 Nov 10 03:53 ef376ffc-983c-4cab-859a-2b8d6ba5faf5 -> ../../dm-1

Now that we have the UUID, let's proceed with encrypting it and verifying if the LUKS key is sent to Vault! Run the following command, replacing the UUID and block device with your own:

[root@test ~]#  vaultlocker encrypt --uuid 65242782-090c-44ab-8808-289b5903a6a6 /dev/sdb1

You should receive an output similar to this:

DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): vault.haynet.host:80

DEBUG:urllib3.connectionpool:http://vault.haynet.host:80 "POST /v1/auth/approle/login HTTP/1.1" 200 487

INFO:vaultlocker.dmcrypt:LUKS formatting /dev/sdb1 using UUID:65242782-090c-44ab-8808-289b5903a6a6

INFO:vaultlocker.dmcrypt:udevadm trigger block/add for /dev/sdb1

INFO:vaultlocker.dmcrypt:udevadm settle /dev/disk/by-uuid/65242782-090c-44ab-8808-289b5903a6a6

DEBUG:urllib3.connectionpool:http://vault.haynet.host:80 "POST /v1/vaultlocker/test.haynet.host/65242782-090c-44ab-8808-289b5903a6a6 HTTP/1.1" 204 0

DEBUG:urllib3.connectionpool:http://vault.haynet.host:80 "GET /v1/vaultlocker/test.haynet.host/65242782-090c-44ab-8808-289b5903a6a6 HTTP/1.1" 200 864

INFO:vaultlocker.dmcrypt:LUKS opening 65242782-090c-44ab-8808-289b5903a6a6

INFO:root:Enabling systemd unit for vaultlocker-decrypt@65242782-090c-44ab-8808-289b5903a6a6.service

Created symlink from /etc/systemd/system/multi-user.target.wants/vaultlocker-decrypt@65242782-090c-44ab-8808-289b5903a6a6.service to /usr/local/lib/systemd/system/vaultlocker-decrypt@.service.
[root@test ~]# 

I've added line breaks for readability. In summary, it worked flawlessly!

It successfully accessed the Vault cluster, formatted the disk, encrypted it, and then extracted the hostname of the machine. Afterward, it created a new secret in the /vaultlocker backend, storing the LUKS key under the disk's UUID.

Let's verify this in the UI:

Now, onto the final step... mounting at boot.

Setting up the service file

Vaultlocker has generated a systemd service file for us. While the current configuration decrypts the device on boot, we also want it to mount. Let's add the mount command to the service file:

[Unit]
Description=vaultlocker retrieve: %i
DefaultDependencies=no
After=networking.service

[Service]
Type=oneshot
KillMode=none
Environment=VAULTLOCKER_TIMEOUT=10000
ExecStart=/bin/sh -c 'vaultlocker --retry $VAULTLOCKER_TIMEOUT decrypt %i && /usr/bin/mount -t ext4 /dev/mapper/crypt-65242782-090c-44ab-8808-289b5903a6a6 /test'
TimeoutSec=0

[Install]
WantedBy=multi-user.target

This addition ensures that the device is mounted to /test after decryption.

With these steps completed, your setup should be ready for use.

PreviousMongoDB admin passwordNextVM SSH Keys

Last updated 1 year ago