Installing the vault
Version in this post is: Vault v1.18.3
The steps are from freebsd fundation they are good and work, you just have to make sure that the service starts correctly.
The vault.hcl
root@Hashicorp-Vault:/ # cat /usr/local/etc/vault.hcl
listener "tcp" {
address = "ip:8200" (1)
tls_disable = 1
}
storage "file" {
path = "/var/db/vault"
node_id = "v"
}
cluster_addr = "ip:8201" (2)
api_addr = "ip:8200" (3)
ui = true| 1 | It is the ip address of the jail. |
| 2 | same but with different port. |
| 3 | same. |
connection refused
For some reason the connection with the vault fails, in my case it is because the vault.hcl file is not being read correctly, and it can throw this error.
Get "http://192.168.1.21:8200/v1/sys/seal-status": dial tcp 192.168.1.21:8200: connect: connection refusedroot@vault-test:~ # vault server -config /usr/local/etc/vault.hcl
Error initializing core: Failed to lock memory: cannot allocate memory
This usually means that the mlock syscall is not available.
Vault uses mlock to prevent memory from being swapped to
disk. This requires root privileges as well as a machine
that supports mlock. Please enable mlock on your system or
disable Vault from using it. To disable Vault from using it,
set the `disable_mlock` configuration option in your configuration
file.
2025-01-27T11:02:28.636Z [INFO] proxy environment: http_proxy="" https_proxy="" no_proxy=""
2025-01-27T11:02:28.717Z [INFO] incrementing seal generation: generation=1env o export
In our case none of them will work, it is because of our shell when starting the jail.
env VAULT_ADDR=http://10.10.0.33:8200 vault operator initIf the VAULT_ADD is not set correctly, we have
WARNING! VAULT_ADDR and -address unset. Defaulting to https://127.0.0.1:8200.Setting environment correctly
In jail if we do a echo SHELL we have bincsh it will work is to use the setenv.
root@vault-test:/etc # setenv VAULT_ADDR ip:8200
root@vault-test:/etc # echo $VAULT_ADDR
ip:8200
root@vault-test:/etc # service vault start
Starting vault.vault server -config
This is the command required for execution under background, very important for the connection to take place.
vault server -config /usr/local/etc/vault/vault.hclroot@vault-test:/etc # service vault start
Starting vault.
root@vault-test:/etc # vault operator init
Unseal Key 1: token
Unseal Key 2: token
Unseal Key 3: token
Unseal Key 4: token
Unseal Key 5: token
Initial Root Token: token
Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.
Vault does not store the generated root key. Without at least 3 keys to
reconstruct the root key, Vault will remain permanently sealed!
It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.
root@vault-test:/etc # echo $SHELLSaving in the environment
We save the variable in the /etc/csh.cshrc file so that every time we enter the jail the variable is found, and we have no error of connection refused.
root@Hashicorp-Vault:~ # nano /etc/csh.cshrc
# System-wide .cshrc file for csh(1).
setenv VAULT_ADDR http://192.168.1.21:8200Creating aliases
As easy as
alias vault-server-config="vault server -config /usr/local/etc/vault.hcl"With every jail startup we must execute this vault-server-config
The UI
Unseal process
In the ui enter 3 of the 5 passwords that were generated with the command vault operator init
The seal from the UI
From the UI, we can seal the vault again, haha this reminded me of the red trunk of memories. 😂
Secrets Management
Normally when looking for a secret, we will have error, because we need at least Initial Root Token: en el environment
| We can set it up with |
setenv VAULT_TOKEN your-token (1)
nano /etc/csh.cshrc (2)
source /etc/csh.cshrc (3)| 1 | setting in the environmnet. |
| 2 | looking at it permanent. |
| 3 | we update the .cshrc. |
Per console
| Before without setting the token in the environment, we could not authenticate ourselves as is. |
root@Hashicorp-Vault:/ # vault read cubbyhole/mi.secreto
Error making API request.
URL: GET http://addreess/v1/sys/internal/ui/mounts/secret/my-secret
Code: 403. Errors:
* permission denied| After setting it |
root@Hashicorp-Vault:~ # vault read cubbyhole/mi.secreto
Key Value
--- -----
test mi.secretoHttp way
The Initial Root Token
|
It will be useful to authenticate us in the web via token, also to consult the api and to obtain secrets, for example with this curl we can obtain a secret.
-
The
X-Vault-Tokenheader is sent when the request is made, with theInitial Root Token
curl --location 'http://ip:8200/v1/cubbyhole/mi.secreto' \
--header 'Accept: */*' \
--header 'Accept-Language: es,en;q=0.9,fr;q=0.8,zh-TW;q=0.7,zh-CN;q=0.6,zh;q=0.5' \
--header 'Connection: keep-alive' \
--header 'DNT: 1' \
--header 'Referer: http://ip:8200/ui/vault/secrets/cubbyhole/list' \
--header 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \
--header 'X-Vault-Token: YourToken' (1)| 1 | This is actually the Initial Root Token |
Giving an answer like this
{
"request_id": "8ac9f6c5-9f08-12f3-ed87-70de1ab96842",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"test": "mi.secreto" (1)
},
"wrap_info": null,
"warnings": null,
"auth": null,
"mount_type": "cubbyhole" (2)
}| 1 | The secret. |
| 2 | Secret assembly point. |
Plugin for PostgreSQL
Installing the postgreSQL plugin
It will allow us to dynamically manage database credentials (users and passwords). Vault can generate temporary credentials in PostgreSQL, which increases security and eliminates the need to manually manage static credentials.
We can configure it through the UI or by console.
From the UI
We must create a new PostgreSQL database secrets engine and using databases is quite intuitive.
The connection chain must meet the requirements e.g.
postgresql://user:password@ip_address:port/database?