-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Conversation
|
||
import "context" | ||
|
||
type ACMEBillingSystemView interface { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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...
There was a problem hiding this 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.
|
||
var realized []string | ||
for _, identifier := range identifiers { | ||
realized = append(realized, fmt.Sprintf("%s/%s", identifier.Type, identifier.OriginalValue)) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
|
||
import "context" | ||
|
||
type ACMEBillingSystemView interface { |
There was a problem hiding this comment.
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
There was a problem hiding this 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") |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
||
namespace := "" | ||
mountName := mount | ||
if mount != "pki" { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(setupAcmeBackend
in particular).
917ee5b
to
ee2fa79
Compare
@miagilepner @stevendpclark @kitography Ok, updated with review feedback. Let me know what y'all think :-) |
19092a0
to
0c17226
Compare
0c17226
to
8882a3e
Compare
@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>
8882a3e
to
f232ed6
Compare
clientID := base64.RawURLEncoding.EncodeToString(identifiersHash[:]) | ||
|
||
// Log so users can correlate ACME requests to client count tokens. | ||
activityType := "acme" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me!
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>
c75dc21
to
0c402e5
Compare
Thanks all for the reviews! Setting to auto-merge :-) |
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.