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

feat: Support publishing new log entries to Pub/Sub topics #1561

Closed
wants to merge 1 commit into from

Conversation

jalseth
Copy link
Contributor

@jalseth jalseth commented Jun 24, 2023

Summary

Adds initial support publishing new log entries to Pub/Sub topics. Interested parties can subscribe to the topic in order to receive notifications when new entries are added.

This relates to #191.

Release Note

  • New features: Added support publishing new log entries to Pub/Sub topics
  • Config changes: Added the rekor_server.new_entry_publisher flag to configure the Pub/Sub topic to send notifications to when a new log entry is added. This flag is optional.

Documentation

This is a TODO still. I would like feedback on the PR before writing the docs.

@jalseth jalseth requested a review from a team as a code owner June 24, 2023 19:54
@jalseth jalseth force-pushed the add-pubsub branch 2 times, most recently from eac292f to f1ecb71 Compare June 25, 2023 00:42
@codecov
Copy link

codecov bot commented Jun 25, 2023

Codecov Report

Merging #1561 (472860e) into main (a1349da) will decrease coverage by 0.43%.
The diff coverage is 23.80%.

❗ Current head 472860e differs from pull request most recent head 9fd111e. Consider uploading reports for the commit 9fd111e to get more accurate results

@@            Coverage Diff             @@
##             main    #1561      +/-   ##
==========================================
- Coverage   67.09%   66.67%   -0.43%     
==========================================
  Files          83       85       +2     
  Lines        8389     8490     +101     
==========================================
+ Hits         5629     5661      +32     
- Misses       2086     2150      +64     
- Partials      674      679       +5     
Flag Coverage Δ
e2etests 48.36% <30.55%> (-0.01%) ⬇️
unittests 47.54% <14.06%> (-0.31%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/api/entries.go 64.05% <14.28%> (-0.82%) ⬇️
pkg/pubsub/gcp/gcp.go 18.75% <18.75%> (ø)
pkg/pubsub/pubsub.go 23.52% <23.52%> (ø)
pkg/api/api.go 68.86% <33.33%> (-3.30%) ⬇️
cmd/rekor-server/app/root.go 60.60% <100.00%> (+1.65%) ⬆️

... and 2 files with indirect coverage changes

Copy link
Member

@bobcallaway bobcallaway left a comment

Choose a reason for hiding this comment

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

Thanks so much @jalseth for the contribution! I put some thoughts inline; tagging @haydentherapper @vaikas @lukehinds for thoughts here too

pkg/api/api.go Outdated Show resolved Hide resolved
}

func (p *Publisher) Publish(ctx context.Context, entry models.LogEntryAnon) error {
data, err := json.Marshal(entry)
Copy link
Member

Choose a reason for hiding this comment

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

instead of JSON marshalling models.LogEntryAnon directly, we should really convert this into the Sigstore bundle format using the two methods in https://github.com/sigstore/rekor/blob/main/pkg/tle/tle.go that can convert models.LogEntryAnon into the bundle format JSON.

Copy link
Member

Choose a reason for hiding this comment

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

We had also talked about potentially defining a https://cloudevents.io/ schema for these messages, which would be nice to do from the start. Thoughts?

Copy link
Contributor Author

@jalseth jalseth Jun 25, 2023

Choose a reason for hiding this comment

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

Ack re using the TLE methods.

I wasn't aware of the Cloud Events spec, but it seems reasonable to follow. I had planned on adding some of these anyway in a future PR, I can tackle that then if it is OK with you. I prefer to keep individual PRs smaller and easier to review, atomically roll-back if needed, etc.

Edit: I saw the example and realized the attributes are encoded in the message rather than just metadata, which would change the message significantly. I guess we do need to decide this now rather than later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bobcallaway I have defined a proto for this in sigstore/protobuf-specs#85. I opted to use the JSON format [1] instead of the protobuf format [2] for the initial implementation for better compatibility with PubSub providers (ex AWS SNS) which require JSON for event filtering to work. We can consider also publishing the protobuf format to a second topic in the future if there's demand. Please take a look when you have time.

[1] https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-format.md
[2] https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/protobuf-format.md

Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about reusing the existing TransparencyLogEntry type? This would make each pub/sub message larger, but would prevent diverging message contents and allow for verification of each message (since each message will contain an inclusion proof).

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I missed that this would be encoded in data. Could we use the TLE type instead and annotate the type with JSON annotations if needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bobcallaway @haydentherapper I wasn't happy with the approach in this PR, so I have rewritten it on a new branch and opened a separate PR: #1580. Apologies for the churn, but I think the new approach is much better.

pkg/pubsub/gcp/gcp.go Show resolved Hide resolved
pkg/pubsub/pubsub.go Outdated Show resolved Hide resolved
pkg/api/entries.go Show resolved Hide resolved
pkg/api/entries.go Outdated Show resolved Hide resolved
pkg/api/entries.go Outdated Show resolved Hide resolved
@jalseth jalseth force-pushed the add-pubsub branch 2 times, most recently from 80ecd6e to 472860e Compare June 25, 2023 18:42
pkg/pubsub/pubsub.go Outdated Show resolved Hide resolved
pkg/pubsub/pubsub.go Outdated Show resolved Hide resolved
Adds initial support publishing new log entries to Pub/Sub topics. Interested parties can subscribe to the topic in order to receive notifications when new entries are added.

Signed-off-by: James Alseth <[email protected]>
@jalseth
Copy link
Contributor Author

jalseth commented Jul 8, 2023

Closing in favor of #1580

@jalseth jalseth closed this Jul 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants