Hi all,
I’m running a configuration similar to peterverraedt on Github.
He proposed a PR in order to add TLS certificate extensions as metadata to be used in vault policy templates: auth/cert: Add certificate extensions as metadata by peterverraedt · Pull Request #13348 · hashicorp/vault · GitHub (now part of v1.10.0-rc1)
Context:
-
I’m using Puppet agent on multiple nodes. Each node connects to Vault using cert authentication
-
I need to set a dynamic Vault ACL policy according to data retrieved from the client certificate. These informations are set in the ASN1 extensions carried by the certificate. For example:
path “secret/<project_name>/<environment_name>/”* {
}
-
I’m using the feature developed by peterverraedt: I already set the Allowed metadata extensions in the cert role
I’m referring to the documentation : ACL Policy Path Templating to write the policies . Unfortunatly, I couldn’t find a way to retrieve these attributes. Certificate extensions are not mentioned in the article.
Did someone already worked with this feature ?
Thanks,
Maxime.
It looks like certificate extensions are still not registered in Vault with this feature.
I made a PR to solve this issue: https://github.com/hashicorp/vault/pull/14419
Hey!
Could you perhaps share your cert auth role and returned metadata of the entity?
You should be able to retrieve them from the entities metadata in the ACL path identity.entity.metadata.<key>. In this case the key is the string consisting of the OID numbers separated by a dash.
Hi @RemcoBuddelmeijer ,
Here is the result of my cert role:
vault read auth/cert/certs/client
Key Value
--- -----
allowed_common_names <nil>
allowed_dns_sans <nil>
allowed_email_sans <nil>
allowed_metadata_extensions [1.3.6.1.4.1.34380.1.1.6 1.3.6.1.4.1.34380.1.1.13 1.3.6.1.4.1.34380.1.1.12 1.3.6.1.4.1.34380.1.1.7 1.3.6.1.4.1.34380.1.1.15]
allowed_names <nil>
allowed_organizational_units <nil>
allowed_uri_sans <nil>
certificate -----BEGIN CERTIFICATE-----*content-*----END CERTIFICATE-----
display_name client
required_extensions []
token_bound_cidrs []
token_explicit_max_ttl 0s
token_max_ttl 0s
token_no_default_policy false
token_num_uses 0
token_period 0s
token_policies [client-policy]
token_ttl 0s
token_type default
I should be able to request these extensions as you said using this path: identity.entity.metadata.<oid>.
However, nothing is stored in entity metadata:
I don’t know the exact reason behind this behavior. However, using my latest PR, I’m able to store theses oids instead in the entity alias and it’s working now:
I’m able to retrieve extensions using this path: identity.entity.alias.<mount_path>.metadata.<oid>.
Couldn’t this perhaps be an UI issue? Could you double check if the metadata is present when doing a CLI/HTTP call to your entity?
Can’t think of any reason why the metadata wouldn’t be visible in the entity but would be in the alias. If this is not the case, then it’s a bug that should be fixed when serving metadata for the entity and should be fixed in that spot.
It looks like a bug:
vault read identity/entity/id/<id>
Key Value
--- -----
aliases *hidden*
creation_time 2022-03-09T09:34:19.000485594Z
direct_group_ids []
disabled false
group_ids []
id 9d884cf9-cad5-852a-d16d-1e7bcae997bf
inherited_group_ids []
last_update_time 2022-03-09T09:34:19.000485594Z
merged_entity_ids <nil>
metadata <nil>
name entity_8761bb51
namespace_id root
policies []
Alright in that case the metadata saving should be tackled!
I am pretty sure that with the PR you currently made it will be blocked by some “backwards compatibility” rules.
My suggestion would be to create either a new issue for this, or update the already existing issue. From there on a PR could be created. Would you be interested in making this PR yourself or do you rather have someone else do this?
I’ll handle it. I think this issue extends over other auth methods (yet to be confirmed, but metadata are missing when using LDAP authentication).
Feel free to tag me in the issue and/or PR. Curious to see where this ends in!
1 Like
