Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start counting ACME certificate issuance as client activity #20520

Merged
merged 12 commits into from
May 17, 2023

Conversation

cipherboy
Copy link
Contributor

This enables client count (activity log events) for ACME certificate issuance. Per consensus reached internally, this creates events based upon the unique identifiers requested during issuance. This interface is presently only intended for ACME billing within the builtin PKI plugin, but changes to system view could be made in the future to make this a more generally available interface, including to external plugins. Today, this goes into the non-entity token bucket.

@cipherboy cipherboy added enhancement core Issues and Pull-Requests specific to Vault Core secret/pki pr/no-changelog labels May 4, 2023
@cipherboy cipherboy added this to the 1.14 milestone May 4, 2023

import "context"

type ACMEBillingSystemView interface {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I like this or if we want to rename it now to just BillingSystemView or ActivityEventSystemView or similar.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think it's good to make it a bit more general, both of your other suggestions seem good to me

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... Until we commit to the work in a later release, I'm inclined to leave this as ACME-specific; we don't want others attempting to use this, though admittedly it will only work with builtin plugins for the time being...

Copy link
Contributor

@stevendpclark stevendpclark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but I'll let someone from vault-core comment on the system view and activity_log changes.

builtin/logical/pki/acme_billing_test.go Outdated Show resolved Hide resolved

var realized []string
for _, identifier := range identifiers {
realized = append(realized, fmt.Sprintf("%s/%s", identifier.Type, identifier.OriginalValue))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: would it be helpful for debugging or anything else to add a method to ACMEIdentifier that returns this formatted string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the only place referring to these identifiers in this construction; logging is done below in the system view interface post-conversion, and everywhere else in the API uses JSON or refers by parent identifier value (order ID/authz ID)...

Thoughts @stevendpclark?

builtin/logical/pki/acme_billing_hack.go Outdated Show resolved Hide resolved

import "context"

type ACMEBillingSystemView interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think it's good to make it a bit more general, both of your other suggestions seem good to me

vault/acme_billing_system_view.go Outdated Show resolved Hide resolved
builtin/logical/pki/acme_billing_test.go Show resolved Hide resolved
Copy link
Contributor

@kitography kitography left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks pretty good :)


// Enable additional mounts.
setupAcmeBackendOnClusterAtPath(t, cluster, client, "pki2")
setupAcmeBackendOnClusterAtPath(t, cluster, client, "ns1/pki")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this make sense in OSS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OSS doesn't have namespaces, but it does have nested paths. So this does work and mounts it at ns1/pki, it just isn't a true Enterprise namespace.

builtin/logical/pki/acme_billing_test.go Outdated Show resolved Hide resolved

namespace := ""
mountName := mount
if mount != "pki" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we not set up mount "pki" here? Like, surely setupAcmeBackendOnClusterAtPath(t, cluster, client, "pki") should mount pki at path pki?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pki is already mounted by another helper that calls this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(setupAcmeBackend in particular).

vault/acme_billing_system_view.go Outdated Show resolved Hide resolved
@cipherboy cipherboy force-pushed the cipherboy-start-billing-acme branch from 917ee5b to ee2fa79 Compare May 15, 2023 14:55
@cipherboy
Copy link
Contributor Author

@miagilepner @stevendpclark @kitography Ok, updated with review feedback. Let me know what y'all think :-)

@cipherboy cipherboy force-pushed the cipherboy-start-billing-acme branch from 19092a0 to 0c17226 Compare May 15, 2023 15:51
@cipherboy cipherboy force-pushed the cipherboy-start-billing-acme branch from 0c17226 to 8882a3e Compare May 16, 2023 13:31
@cipherboy
Copy link
Contributor Author

@miagilepner Updated! :-)

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
This begins to add custom types of events; presently these are counted
as non-entity tokens, but prefixed with a custom ClientID prefix.

In the future, this will be the basis for counting these events
separately (into separate buckets and separate storage segments).

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
@cipherboy cipherboy force-pushed the cipherboy-start-billing-acme branch from 8882a3e to f232ed6 Compare May 17, 2023 14:45
clientID := base64.RawURLEncoding.EncodeToString(identifiersHash[:])

// Log so users can correlate ACME requests to client count tokens.
activityType := "acme"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind making this a const? It will be useful for the client_type changes that I'm working on. No worries if not. I can make that change as well.

Copy link
Contributor Author

@cipherboy cipherboy May 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can make it a const, but I was a little unclear where I wanted it to live. I think ideally, if we were to hoist it to a proper interface it should probably live in sdk/logical/ and each consumer of the interface would then define their own constant there that everyone could rely on?

But since this is an internal-ish interface only for use by ACME right now, I was thinking that leaving it here (as an internal implementation detail) would be good for now...

Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me!

vault/activity_log.go Outdated Show resolved Hide resolved
cipherboy and others added 8 commits May 17, 2023 11:39
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Without an additional parameter, SystemView could be of a different
internal implementation type that cannot be directly casted to in OSS.
Use a separate parameter for the managed key system view to use instead.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: miagilepner <mia.epner@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
@cipherboy cipherboy force-pushed the cipherboy-start-billing-acme branch from c75dc21 to 0c402e5 Compare May 17, 2023 15:39
@cipherboy
Copy link
Contributor Author

Thanks all for the reviews! Setting to auto-merge :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues and Pull-Requests specific to Vault Core enhancement pr/no-changelog secret/pki
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants