Vault, Capabilities, and SystemD: resolved.
• Mark Eschbach
So, if you’ve been following along you’ll now this is my like 4th time trying to figure out what is going on with the following line:
vault-dev.service: Main process exited, code=exited, status=213/SECUREBITS
I finally figured it out. After reading someone’s question on StackOverflow several times I finally understand what they were trying to say. Turns out this is apart of the Linux Capability System as I thought. Eventually, after trying random things I stumbled across the setcap
and getcap
. I generally default to the option of -v
to mean verbose. In this context it means verify; took embarassingly long to figure that out. A capability is a mechanism to grant a specific administrtive level feature to an application without having the application run as run.
In the context of this problem Vault 0.8.0
only requires the permission CAP_IPC_LOCK
which allows it to lock memory via the mlock
facaility to prevent confidentail material being leaked into the swap sectinons on disk. Vault doesn’t require teh CAP_SYSLOG
though. In terms of the file system you have to grant the capability to the Vault binary using setcap cap_ipc_lock=+eip vault
. Next up is to setup the SystemD file. The keys are the Capabilities
actually being AmbientCapabilities
matching CapabilityBoundingSet
.
[Unit]
Description=Vault
After=network-online.target
[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectSystem=full
NoNewPrivileges=yes
SecureBits=keep-caps-locked
AmbientCapabilities=CAP_IPC_LOCK
CapabilityBoundingSet=CAP_IPC_LOCK
Environment=GOMAXPROCS=24
ExecStart=vault server -config=vault.hcl
KillSignal=SIGINT
TimeoutStopSec=30s
Restart=on-failure
StartLimitInterval=60s
StartLimitBurst=3
User=vault
Group=vault
Type=simple
[Install]
WantedBy=multi-user.target