auth/cert: Add metadata to identity-alias

[peterverraedt]

Add metadata to logical.Alias (the identity alias) too, in addition
to the metadata added to logical.Auth. This is analogous to the
behaviour of the ldap and approle auth providers.

CC: @pmmukh

Fixes: #14418

Signed-off-by: Peter Verraedt peter.verraedt@kuleuven.be

[hghaf099]

Thank you for your contribution. There has been an update on the original GH issue. I am going to post a link here for reference. #14418 (comment)

[HridoyRoy]

Hi @peterverraedt ,
Thanks for submitting this PR!

This change makes sense to us as the right path forward for enabling using certificates metadata in ACL templating. However, we're worried about storage concerns regarding this change, so we'd like for this to be an opt-in feature. One option is to add this to the role config, but it might also be possible that an extra config endpoint is needed.
Thanks again!

[peterverraedt]

@HridoyRoy I've added a config value to the existing configuration endpoint of the auth method mount. As the identity aliases are linked to the auth mount as a whole rather than to the specific role, this seems to be the most logical place (either all identity aliases have some metadata, or none have metadata).

The amount of stored metadata is limited to these five fields

vault/builtin/credential/cert/path_login.go

Lines 98 to 102 in c5cf53f

	"cert_name": matched.Entry.Name,
	"common_name": clientCerts[0].Subject.CommonName,
	"serial_number": clientCerts[0].SerialNumber.String(),
	"subject_key_id": certutil.GetHexFormatted(clientCerts[0].SubjectKeyId, ":"),
	"authority_key_id": certutil.GetHexFormatted(clientCerts[0].AuthorityKeyId, ":"),

and what the user specifies as "allowed_metadata_extensions". The latter is specified on role level as it could easily differ depending on the trusted CAs.

[peterverraedt]

@HridoyRoy What is the current status of this PR?

[pmmukh]

Hey @peterverraedt ! So we discovered a potential entity bloat bug when it comes to adding data to the alias metadata, and there's currently a PR open for it that we're in the process of reviewing and merging, once that is done the plan is to review either this or the other open PR fixing the issue.

[pmmukh]

Hi @peterverraedt ! I'm currently taking a look at this PR, and i'll drop a proper review shortly, but off the bat I had a couple asks, if they make sense to you.

1. Since the goal is to use the certificate info for policy templating, could we potentially have a test that exercises that code path i.e store a secret in a path with say the cert common name, create a policy with that template, and check that a token with the policy works to read the secret ?
2. I think this PR should also remove the place where Metadata is currently being set i.e in auth.Metadata, as we can't use it for templating since its in the token metadata, and so I don't think there's a practical way of using it. wdyt ?

[peterverraedt]

Hi @pmmukh, back from holidays now.

1. Yes, that is a good idea, I'll try to implement during the next days.
2. I'm following what is done in the ldap and approle auth providers: https://github.com/hashicorp/vault/blob/main/builtin/credential/approle/path_login.go#L339 and https://github.com/hashicorp/vault/blob/main/builtin/credential/ldap/path_login.go#L90. The auth.Metadata is used in the metadata associated with the token that the user will receive after login, I am not sure whether it is merged with the alias.Metadata there? But I guess it could be removed, it is up to you.

[peterverraedt]

Hi @pmmukh, I added a test case for testing whether usage of metadata in acl policies works.

I can also confirm for your second question that the metadata that is set in Auth.Metadata ends up as metadata associtated with the token, and while this does not relate at all to the acl policy templates, it still might be useful.

[HridoyRoy]

👍 lgtm!