feat: Add option to use Ingest Key IDs for access control, as well as full API Keys#1788
Closed
feat: Add option to use Ingest Key IDs for access control, as well as full API Keys#1788
Conversation
## Summary - Add CHANGELOG entry for v3.1.1 - Add RELEASE_NOTES entry for v3.1.1 ## Changes in this release ### Features - feat: Allow configuration of additional headers (#1771) by @mterhar ### Fixes - fix: Create rules-based samplers per environment (#1787) by @TylerHelmuth - fix: apply UseClusterSize cfg (#1786) by @VinozzZ - fix: Find IPv6 addresses properly (#1772) by @mterhar - fix: bump husky to latest main (#1785) by @TylerHelmuth ### Maintenance - maint: bump husky to v0.41.0 (#1790) by @TylerHelmuth ## Test plan - [ ] Review CHANGELOG entry formatting matches previous releases - [ ] Review RELEASE_NOTES summary is accurate and user-friendly - [ ] Confirm version number is correct (v3.1.1) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Add AdditionalAttributes map[string]string to OTelMetricsConfig, mirroring the existing HoneycombLoggerConfig.AdditionalAttributes. The additional attributes are injected as resource attributes on the OTLP metrics exporter, allowing deployment-specific metadata (cluster ID, environment, etc.) to be attached to all outgoing metrics. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Benchmark covers no-filtering, ReceiveKeys, ReceiveKeyIDs, and combined scenarios at 10 and 100 key list sizes. Provides regression protection since IsAccepted is called on every incoming span. Baseline on Apple M1 Max: - no_filtering: ~2ns/op, 0 allocs - 10 keys match: ~21ns/op, 0 allocs - 100 keys match: ~230ns/op, 0 allocs - 100 keys no match: ~160ns/op, 3 allocs (error formatting) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ry into davin/raas-management
Contributor
Author
|
Going to close this, as I have these changes going into a new PR that I'll be opening shortly. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Short description of the changes
With Honeycomb ingest keys not allowing users to access the full API key after creation, it could be difficult to use them in the AccessKeys configuration to restrict which API keys could send data through Refinery. This change adds a
ReceiveKeyIDsfield under theAccessKeysconfig group which allows you to put in the ingest api key ID instead of a full API key. There's some updates to the traffic validation where we use the auth endpoint to cache API key and environment name mappings to also have mappings for key to key ID, so that we can validate that a key matches an ID in the list.Tests were added, and I've also built and run this manually to validate that it both allows traffic using a key that has an allowed ID, and blocks traffic using a key with an id that's not listed.
This also benefits future integrations with beekeeper, as we're not able to access ingest keys programmatically with management keys, but we can access the IDs, beekeeper would be able to maintain a list of allowed ingest keys on a Refinery cluster, which will help future RaaS deployments.