Audit and server log the unseal and generate-root operations

[vishalnayak]

No description provided.

[tburt11]

I am concerned that the decode command line is stored in the bash history and in some cases, logged for audit purposes.

This command:
vault generate-root -otp R1gnhIAvatKSWHI6Tm4Lag== -decode hHlUpNFqm9UCLl1DVCV4XA==
is stored in bash history and re-executing this command produces the identical new root token again and again.

Am I missing something?

[jefferai]

Depending on your shell configuration it could be. You can:

1. Turn history off
2. Source the value from a file into stdin and pipe it in
3. Delete your history
4. Write and/or use use a different XOR function that doesn't operate on CLI arguments
5. Ensure that you have revoked the root token as soon as you are done using it

You have lots of options!

[rtlong]

I just came across this and I'm very surprised it's missing from the audit log. This seems like an operation one definitely wants to see in an audit log.

I notice there's no activity on this in over a year. Could anyone provide an update on the status of this effort?

[metalivedev]

Even though the keys are not associated with vault users, they could be associated with GPG keys if they were used during keying. Could the log indicate which keys were used based on the GPG key they were originally encrypted-with?

[kiwivogel]

@rtlong I'd guess this is mainly due to the fact that only an active node writes audits and that an unsealed node by definition is inactive. But I agree that a standby node should either forward these operations to the active node for auditing or buffer it and then audit it when it becomes active itself.

[rfc1036]

Also seal operators are not correctly logged: the audit log will contain a request object but not the corresponding response object. Unseal requests are not logged at all.

This is very disappointing for me, because I have been trying to make root access to the server conditional on Vault being sealed.

[ncabatoff]

Also seal operators are not correctly logged: the audit log will contain a request object but not the corresponding response object.

This is unfortunate but not surprising: once Vault is sealed just about everything internal shuts down, making it difficult to ensure that the response gets written.

Unseal requests are not logged at all.

generate-root operations are now audit logged, as of 1.3. This is the first exception to the general rule that only authenticated and login endpoints are audit logged. In principle we could extend this to audit log unseal requests, but I'm less persuaded of the benefit of auditing unseal requests. Note that we won't be able to record failed unseal attempts, since the audit device configuration is kept behind the sealed barrier.

This is very disappointing for me, because I have been trying to make root access to the server conditional on Vault being sealed.

I don't understand this goal. When Vault is sealed, no vault-token using operations can succeed, only unseal requests - and those use unseal keys, not root tokens.

[rfc1036]

I mean OS-level root access to the server, not using Vault root tokens. The goal is to make harder for the local system administrator to tamper with Vault, e.g. with ptrace.

[ncabatoff]

generate-root operations are now audit logged, as of 1.3

My mistake, as of 1.4 (#8301).

[vishalnayak]

Issues that are not reproducible and/or not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.