lrstanley / vault-unseal Goto Github PK

🌧 Describe the problem

When selinux is set to enforcing on AlmaLinux 9, vault-unesal seg faults.

⛅ Expected behavior

vault-unseal runs successfully

🔄 Minimal reproduction

$ cat /etc/os-release
NAME="AlmaLinux"
VERSION="9.2 (Turquoise Kodkod)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.2"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.2 (Turquoise Kodkod)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.2"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.2"
$ getenforce
Enforcing
$ ./vault-unseal_linux_amd64
Segmentation fault (core dumped)
$ setenforce permissive
$ ./vault-unseal_linux_amd64
timestamp=2024-06-17T21:33:46.365967729Z level=fatal message="error reading config" environment= error="not enough nodes in node list (must have at least 3)" version=0.5.1
$ setenforce enforcing
$ ./vault-unseal_linux_amd64
Segmentation fault (core dumped)

💠 Version: vault-unseal

v0.5.1

🖥 Version: Operating system

linux/other

⚙ Additional context

selinux audit logs:

time->Mon Jun 17 21:33:54 2024
type=PROCTITLE msg=audit(1718660034.188:251): proctitle="./vault-unseal_linux_amd64"
type=SYSCALL msg=audit(1718660034.188:251): arch=c000003e syscall=10 success=no exit=-13 a0=7f0259070000 a1=1972 a2=5 a3=0 items=0 ppid=945 pid=8595 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="vault-unseal_li" exe="/root/vault-unseal_linux_amd64" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1718660034.188:251): avc:  denied  { execmod } for  pid=8595 comm="vault-unseal_li" path="/root/vault-unseal_linux_amd64" dev="vda1" ino=25219182 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

strace

$ strace ./vault-unseal_linux_amd64
execve("./vault-unseal_linux_amd64", ["./vault-unseal_linux_amd64"], 0x7fffba5c3f00 /* 30 vars */) = 0
open("/proc/self/exe", O_RDONLY)        = 3
mmap(NULL, 2058610, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f69c8530000
mmap(0x7f69c8530000, 2058156, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7f69c8530000
mprotect(0x7f69c8725000, 6514, PROT_READ|PROT_EXEC) = -1 EACCES (Permission denied)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f69c8726163} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)


### 🤝 Requirements

- [X] I believe the problem I'm facing is a bug, and is not intended behavior. [Post here if you're not sure](../discussions/new?category=q-a).
- [X] I have confirmed that someone else has not [submitted a similar bug report](../labels/bug).

✨ Describe the feature you'd like

It would be cool to have the possibility to pass a kubeconfig and use kubernetes proxy verb. It will allow to unseal a kubernetes vault HA cluster from non kubernetes nodes.

🌧 Is your feature request related to a problem?

If you want to run an HA vault cluster exposed only in the cluster.

🔎 Describe alternatives you've considered

• Exposing each pod with an ingress (I don't like the idea to expose something that is not needed).
• Install vault-unseal in the cluster, I don't like the idea to run this software in the same cluster as my vault cluster. For example a compromise node (with a SSH key) can result in discovering vault unseal keys and secret in one time.

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

Can these be changed to debug level messages, to avoid spamming the log with "everything is still working" messages every 15 seconds?

timestamp=2021-04-21T16:28:41.593169277-04:00 level=info message="seal status" addr=https://myserver:8200 environment= version=v0.0.6
timestamp=2021-04-21T16:28:51.602402128-04:00 level=info message="running checks" addr=https://myserver:8200 environment= version=v0.0.6

Hi,
Everything is working great on my cluster. I have email notifications setup and I occasionally (numerous times a day) get the following:
vault-unseal ran into errors when attempting to check seal status/unseal. here are the errors:

14 Jan 22 11:50 GMT :: error: checking seal status: Error making API request.

URL: GET https://node03:8200/v1/sys/seal-status
Code: 500. Errors:

• Unexpected response code: 500

sent from vault-unseal. version: v0.0.8, compile date: 2021-10-17T19:40:03Z, hostname: consul03

These alerts come from any of the three vault-unseal nodes and also report the issue on any of the Vault nodes - so it's not an issue with any specific node.
Can anything be done to reduce these - some sort of further check, increased timeout?

Thanks,
Richie

Hi,
Not an issue, merely a query.
I'm setting up a cluster - three Consul nodes and two Vault nodes.
Does this vault-unseal script have to be on the Vault nodes or can I put it on the three Consul nodes? All instances are running Ubuntu 20.04.

Thanks,
Richie

We have a single Vault instance, but validation for vault_nodes parameter require us to provide at least 3 urls

✨ Describe the feature you'd like

Hi, I'm trying to run vault-unseal as container in my docker swarm instance.
Then I realize to make it work I need to store my tokens in unencrypted format inside the vault-unseal.yaml file in the host.

I think it would be very nice if the vault-unseal support reading token list from separate file, so I can then use docker secrets to store my tokens securely.

🌧 Is your feature request related to a problem?

No response

🔎 Describe alternatives you've considered

--

⚠ If implemented, do you think this feature will be a breaking change to users?

Yes

⚙ Additional context

To make my approach of using vault-unseal clearer, here is the example.

First I create new secret containing the tokens:
echo "aaaaaaaaaaaaaaaaaa,bbbbbbbbbbbbbbb" | docker secret create vault_unseal_tokens_a_b -

Then I can use the stack compose script below to easily spawn new vault-unseal node:

version: '3.8'
services:
  vault_unseal_1:
    image: ghcr.io/lrstanley/vault-unseal:latest
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
    environment:
      - CONFIG_PATH=/vault_unseal_config
      - TOKENS__FILE=/run/secrets/unseal_tokens
    networks:
      - vault-unseal-network
    configs:
      - source: vault_unseal_config
        mode: 0400
    secrets:
      - unseal_tokens

networks:
  vault-unseal-network:
    name: "vault_unseal_network"

configs:
  vault_unseal_config:
    name: "vault_unseal_conf_v1"
    external: true

secrets:
  unseal_tokens:
    name: "vault_unseal_tokens_a_b"
    external: true

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

Options:

• https://github.com/containrrr/shoutrrr (easier to configure, just allow users to pass in url's via cli or env)
• https://github.com/nikoksr/notify

This would likely be a breaking change for existing email support.

✨ Describe the feature you'd like

At the moment the first execution of the seal check is delayed for the CheckInterval because of the time.After statement in the "daemon.go".
So it would be cool if this would be executed immediately after startup of vault-unseal.

🌧 Is your feature request related to a problem?

Not really an problem but an question if this is intentional.
Imagine an high value of CheckInterval (say 300s), so the first check would occur 5m after startup.

🔎 Describe alternatives you've considered

As I'm not an programmer I'm not able to provide a solution for this out of the box.
Maybe the main part of the for loop could be an function so that this could be called once
before the loop starts 🤷 but I'm not sure if this works with the select stuff in golang.

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

🌧 Describe the problem

Hi,

I have a problem with the vault-unseal process, because it is constantly using 100% of the CPU. Apparently the process works correctly. This service is running in a proxmox linux container (LXC) with centos 7.

The version I have installed of vault-unseal is the latest (0.2.2), but this happened with previous versions.

[root@mypc ~]$ rpm -qa | grep vault-unseal
vault-unseal-0.2.2-1.x86_64
[root@mypc ~]$

This is a top capture where you can see the high CPU usage

If you need anything else to diagnose what's going on, I'll be available

Thanks!!!

⛅ Expected behavior

Reduce the high CPU usage of the process

🔄 Minimal reproduction

No response

💠 Version: vault-unseal

v0.2.2

🖥 Version: Operating system

linux/centos

⚙ Additional context

No response

🤝 Requirements

• I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• I have confirmed that someone else has not submitted a similar bug report.

✨ Describe the feature you'd like

I have 5 nodes which are easy to maintain via a shared drive.
Pushing config for each in ./node${i}/config/vault-unseal.yaml on the said shared drive.
Sadly they all remain in the shared drive unless I move them away, which makes the whole process pointless.

It would be nice to:

• load the config from folderA => my case the sahred drive
• save it to folderB (working dir) => some location on the host
• optionally delete it from folderA => or it can be done manually as well, what is important is that it doesn't rely on folderA anymore

Unless you might suggest another way todo.

🌧 Is your feature request related to a problem?

No response

🔎 Describe alternatives you've considered

Manually login into each node and apply the needed changes before launching the cluster.

⚠ If implemented, do you think this feature will be a breaking change to users?

Not sure

⚙ Additional context

It won't affect the others necessarily, it can be made optional.

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

✨ Describe the feature you'd like

It would be cool to deploy vault-unseal via a helm chart in a Kubernetes cluster.

🌧 Is your feature request related to a problem?

No response

🔎 Describe alternatives you've considered

I've considered to write 3 deployments with their respective secret.
With a Helm chart, I will be able to deploy vault-unseal for example in 3 distinct namespaces with a GitOps tool (ArgoCD, Flux...).
In fact, Helm chart is clearly a standard in the Kubernetes ecosystem and it would be a nice-to-have deployment for this very usefull project.

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

✨ Describe the feature you'd like

Hello! Thanks for the cool tool, it would be nice to add a build docker image for the arm64 platform
If nedded i can help with GH Action for this solution

🌧 Is your feature request related to a problem?

Users can run this tool at raspbery pi/orage pi/banaba pi and etc

🔎 Describe alternatives you've considered

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• I have confirmed that someone else has not submitted a similar feature request.
• If implemented, I believe this feature will help others, in addition to solving my problems.
• I have looked into alternative solutions to the best of my ability.
• (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

🌧 Describe the problem

A config file set to 0400 results in an error message:

timestamp=2022-08-23T17:21:33.858258175Z level=fatal message="error reading config" environment= error="permissions of \"/etc/vault-unseal.yaml\" are insecure: r--------, please use 0600" version=0.2.2

⛅ Expected behavior

Config file with 0400 permissions is loaded by the program.

🔄 Minimal reproduction

echo '---' > vault-unseal.yaml
chmod 0400 vault-unseal.yaml
vault-unseal -c vault-unseal.yaml

💠 Version: vault-unseal

0.2.2

🖥 Version: Operating system

linux/alpine

⚙ Additional context

No response

🤝 Requirements

• I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• I have confirmed that someone else has not submitted a similar bug report.

🌧 Describe the problem

In

In

⛅ Expected behavior

The configured CheckInterval is the time between two consecutive checks.

🔄 Minimal reproduction

Set check_interval in yaml:

grep -w check_interval /etc/vault-unseal.yaml
check_interval: 60s

Check the execution times in log:

Aug 29 16:41:11 argos vault-unseal[98884]: timestamp=2022-08-29T16:41:11.250763784+02:00 level=info message="running checks" addr=https://<omit>:8200 environment= version=0.2.3
Aug 29 16:41:11 argos vault-unseal[98884]: timestamp=2022-08-29T16:41:11.272847516+02:00 level=info message="seal status" addr=https://<omit>:8200 environment= version=0.2.3
Aug 29 16:43:11 argos vault-unseal[98884]: timestamp=2022-08-29T16:43:11.273515519+02:00 level=info message="running checks" addr=https://<omit>:8200 environment= version=0.2.3
Aug 29 16:43:11 argos vault-unseal[98884]: timestamp=2022-08-29T16:43:11.313285866+02:00 level=info message="seal status" addr=https://<omit>:8200 environment= version=0.2.3

💠 Version: vault-unseal

vault-unseal version: 0.2.3 [6d0c99e] (linux, amd64), compiled 2022-08-25T00:22:00Z

🖥 Version: Operating system

linux/other

⚙ Additional context

No response

🤝 Requirements

• I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• I have confirmed that someone else has not submitted a similar bug report.

🌧 Describe the problem

If you have not, auto-unseal functionality for on-prem is currently only in enterprise

This is not correct anymore. You actually can do auto-unseal in on-prem Vault OSS. But it does require some configuration, and some resources in a cloud provider like GCP/AWS.

I have set up the open source Vault on-prem in kubernetes with auto-unseal configured to use a key and keyring managed in GCP.

To be clear, I still believe this tool has a purpose. I'm actually considering using it over GCP KMS just so I won't also have to maintain some terraform.

⛅ Expected behavior

This text should be updated. The "why" for this kind of a project would now be something more like, "If you want to maintain a Vault cluster on-prem with auto-unseal functionality without relying on any public cloud KMS assets."

🔄 Minimal reproduction

N/A

💠 Version: vault-unseal

master branch

🖥 Version: Operating system

other

⚙ Additional context

N/A

🤝 Requirements

• I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• I have confirmed that someone else has not submitted a similar bug report.

🌧 Describe the problem

When I issue this command:

vault-unseal --version

I get vault-unseal version: master [latest] (linux, amd64), compiled -

It used to output a version number as well, like 0.3.0. I am using this for my ansible-playbook to see if I need to upgrade vault-unseal.

⛅ Expected behavior

vault-unseal version: 0.4.0 [latest] (linux, amd64), compiled - or at least something that contains the version.

🔄 Minimal reproduction

vault-unseal --version

💠 Version: vault-unseal

v0.40.0

🖥 Version: Operating system

linux/ubuntu

⚙ Additional context

No response

🤝 Requirements

• I believe the problem I'm facing is a bug, and is not intended behavior. Post here if you're not sure.
• I have confirmed that someone else has not submitted a similar bug report.