Hashicorp Vault ACL Policy Templating / for Vault host key signi

ghz 8months ago ⋅ 138 views

Hashicorp Vault ACL Policy Templating / for Vault host key signing

I try to setup secure vault host key signing.

For this I have written the following policy in vault:

path "ssh_host_signer/sign/*" {
  capabilities = ["create", "update"]
  required_parameters = ["cert_type", "public_key", "valid_principals"]
  allowed_parameters = {
    "cert_type" = ["host"],
    "public_key" = [],
    "valid_principals" = ["{{identity.entity.aliases.auth_cert_XXX.name}}"]
  }
}

unfortunately this is not working. With valid_principals" = [] instead in the policy the Key signing works, so the problem have to be there.

I try to sign the host key like this:

vault write ssh_host_signer/sign/host cert_type=host public_key=@/etc/ssh/ssh_host_rsa_key.pub valid_principals=hostname.internal

If I get the entity_id with $ vault token lookup and then the enitity data, I get:

vault read identity/entity/id/__ENTITY_ID__

Key                    Value
---                    -----
aliases                [map[canonical_id:XXX creation_time:1990-XXX custom_metadata:<nil> id:XXX last_update_time:XXX local:false merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:auth_cert_XXX mount_path:auth/cert/ mount_type:cert name:hostname.internal]]
creation_time          XXX
direct_group_ids       []
disabled               false
group_ids              []
id                     XXX
inherited_group_ids    []
last_update_time       XXX
merged_entity_ids      <nil>
metadata               <nil>
name                   entity_XXX
namespace_id           root
policies               []

And the alias data:

vault read identity/entity-alias/id/__ALIAS_ID__

Key                          Value
---                          -----
canonical_id                 XXX
creation_time                XXX
custom_metadata              <nil>
id                           XXX
last_update_time             XXX
local                        false
merged_from_canonical_ids    <nil>
metadata                     <nil>
mount_accessor               auth_cert_XXX
mount_path                   auth/cert/
mount_type                   cert
name                         hostname.internal
namespace_id                 root

Regarding to the documentation that should work: https://developer.hashicorp.com/vault/tutorials/policies/policy-templating#create-templated-acl-policies

So why doesn't this work as described above ("valid_principals" = ["{{identity.entity.aliases.auth_cert_XXX.name}}"]) and how could it be solved that a host can only sign its own keys?

Answers

It seems like there might be an issue with how you're referencing the entity alias name in your Vault policy. Let's try a different approach to ensure that the alias name is properly referenced.

Instead of directly referencing the alias name in the policy, you can use a templated policy to dynamically generate the list of valid principals based on the authenticated entity's alias name. Here's how you can modify your policy to achieve this:

path "ssh_host_signer/sign/*" {
  capabilities = ["create", "update"]
  required_parameters = ["cert_type", "public_key", "valid_principals"]

  # Use a templated ACL policy
  allowed_parameters = {
    "cert_type"       = ["host"],
    "public_key"      = [],
    "valid_principals" = ["{{identity.entity.aliases.auth_cert_XXX.name}}"]
  }
}

In this modified policy:

  • We're still using "valid_principals" = ["{{identity.entity.aliases.auth_cert_XXX.name}}"] to dynamically populate the valid principals based on the authenticated entity's alias name.
  • Make sure to replace auth_cert_XXX with the appropriate mount accessor for your certificate backend.
  • Ensure that the Vault agent or client making the request is authenticated with an entity alias that matches the auth_cert_XXX mount accessor.

By using this approach, Vault will dynamically replace {{identity.entity.aliases.auth_cert_XXX.name}} with the actual alias name of the authenticated entity during policy evaluation. This should ensure that only the specified entity can sign its own keys.