Securing the status endpoint

Vault
1

Hi,
I was surprised to find out that as an unauthenticated user, VAULT_ADDR=https://<Vault_URL> vault status works and gives me the full status information about the cluster. This may also mean that some other endpoints under /sys/ are accessible when not authenticated.

I have double-checked that I did not have VAULT_TOKEN set in my environment. I have also checked vault auth list right after, which resulted in a permission denied as expected.

Would a Deny policy on /sys/* be a solution to lock it down?

Forgive my ignorance; I am new to Vault policies, but in this case what should be the policy subject to make it apply to every unauthenticated principal? I’d appreciate a snippet.

edit: Perhaps this needs to be open in order for the authentication to work in the first place? What’s the most security-conservative configuration that wouldn’t break things?

2

Some Vault endpoints are defined as being anonymously accessible. All login endpoints need to be, since before you’ve logged in, you are by definition anonymous - but some others are too.

Here is a list I parsed out of Vault’s OpenAPI document:

/auth/jwt/oidc/auth_url
/auth/jwt/oidc/callback
/auth/okta/verify/{nonce}
/identity/oidc/.well-known/keys
/identity/oidc/.well-known/openid-configuration
/identity/oidc/provider/{name}/.well-known/keys
/identity/oidc/provider/{name}/.well-known/openid-configuration
/identity/oidc/provider/{name}/token
/pki/ca
/pki/ca/pem
/pki/ca_chain
/pki/cert/ca_chain
/pki/cert/crl
/pki/cert/delta-crl
/pki/cert/{serial}
/pki/cert/{serial}/raw
/pki/cert/{serial}/raw/pem
/pki/crl
/pki/crl/delta
/pki/crl/delta/pem
/pki/crl/pem
/pki/issuer/{issuer_ref}/crl
/pki/issuer/{issuer_ref}/crl/delta
/pki/issuer/{issuer_ref}/crl/delta/der
/pki/issuer/{issuer_ref}/crl/delta/pem
/pki/issuer/{issuer_ref}/crl/der
/pki/issuer/{issuer_ref}/crl/pem
/pki/issuer/{issuer_ref}/der
/pki/issuer/{issuer_ref}/json
/pki/issuer/{issuer_ref}/pem
/pki/ocsp
/pki/ocsp/{req}
/ssh/public_key
/ssh/verify
/sys/generate-root/attempt
/sys/generate-root/update
/sys/health
/sys/init
/sys/internal/specs/openapi
/sys/internal/ui/mounts
/sys/internal/ui/mounts/{path}
/sys/internal/ui/namespaces
/sys/leader
/sys/mfa/validate
/sys/rekey/init
/sys/rekey/update
/sys/rekey/verify
/sys/replication/status
/sys/seal-status
/sys/unseal
/sys/wrapping/lookup

Vault open-source does not contain any way to lock these down, that I know of.

Vault Enterprise has Sentinel EGPs which … might work, but you’d have to be pretty careful not to break some functionality.

I think the pragmatic option is to just accept this is how Vault is designed.

3

Thanks for the confirmation maxb, good to know.