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

[processor/attributes] Support attributes set by server authenticators #9420

Conversation

svrakitin
Copy link
Contributor

@svrakitin svrakitin commented Apr 24, 2022

Description:

Support looking up attributes from client.Info.Auth which is set by extensions implementing configauth.ServerAuthenticator. This way we can attach authentication of the exporter (e.g. OIDC subject) to the telemetry.

User can refer to these attributes by prefixing keys with auth. when using from_context:

attributes/subject:
  actions:
  - key: enduser.id
    from_context: auth.subject
    action: insert

For consistency I added metadata. prefix to refer to actual metadata/header keys. This prefix is optional for backwards compatibility.

Testing:

I added tests to attraction package which has actual extraction logic.

Closes #9241

@svrakitin svrakitin marked this pull request as ready for review April 24, 2022 13:07
@svrakitin svrakitin requested a review from a team April 24, 2022 13:07
@svrakitin svrakitin requested a review from pmm-sumo as a code owner April 24, 2022 13:07
@jpkrohling jpkrohling self-requested a review April 25, 2022 14:57
@jpkrohling jpkrohling changed the title [processor/attributes] Support attributes set by server authenticator [processor/attributes] Support attributes set by server authenticators Apr 26, 2022
Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

LGTM, just the documentation could be a bit better. Thanks for this PR!

CHANGELOG.md Outdated Show resolved Hide resolved
processor/attributesprocessor/README.md Outdated Show resolved Hide resolved
processor/attributesprocessor/README.md Outdated Show resolved Hide resolved
processor/attributesprocessor/README.md Outdated Show resolved Hide resolved
processor/attributesprocessor/README.md Outdated Show resolved Hide resolved
@svrakitin svrakitin requested a review from dmitryax as a code owner April 26, 2022 18:29
@svrakitin
Copy link
Contributor Author

svrakitin commented Apr 26, 2022

@jpkrohling I added logger to the AttrProc and removed its arg from the Process method. Now logger is injected from the processor.

Thanks for suggestions to the docs.

I just noticed there is a relevant issue, thanks for linking it to the PR.

@@ -86,7 +86,7 @@ func TestAttributes_InsertValue(t *testing.T) {
},
}

ap, err := NewAttrProc(cfg)
ap, err := NewAttrProc(cfg, nil)
Copy link
Member

Choose a reason for hiding this comment

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

I won't block the PR for this unless @pmm-sumo agrees with me, but I would prefer the test to be passing zap.NewNop() instead of nil. Remember that your test code shows the good practice for consumers of the main code, and by passing nil, you are sending the message that nil is OK, when it really isn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I don't have a preference here. Gonna update.

func NewAttrProc(settings *Settings) (*AttrProc, error) {
var attributeActions []attributeAction
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) {
if logger == nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think now we might assume that logger is never nil?

Copy link
Contributor Author

@svrakitin svrakitin Apr 26, 2022

Choose a reason for hiding this comment

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

Yeah, it was never nil and that's why passing nil previously worked. I don't want this to fail if nil is passed. :)

Copy link
Member

Choose a reason for hiding this comment

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

It's good to check for nil, but not sure about the outcome: you do want to have access to a logger, it's not an optional parameter, so, you should return an error if it's nil.

Copy link
Member

Choose a reason for hiding this comment

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

I agree, this seems to be unrelated, consider to split a separate PR.

pmm-sumo
pmm-sumo previously approved these changes Apr 26, 2022
@svrakitin
Copy link
Contributor Author

svrakitin commented Apr 26, 2022

Copy link

@rkukura rkukura left a comment

Choose a reason for hiding this comment

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

This all looks good to me - very similar to what I planned to implement when filing #9241, except that I didn't anticipate the logging changes. Please let me know if I can help get this merged.

@svrakitin
Copy link
Contributor Author

svrakitin commented Apr 27, 2022

@rkukura I probably just need someone to rerun unit tests to get over the flaky ones. Thanks.

@jpkrohling
Copy link
Member

Tests restarted

func NewAttrProc(settings *Settings) (*AttrProc, error) {
var attributeActions []attributeAction
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) {
if logger == nil {
Copy link
Member

Choose a reason for hiding this comment

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

It's good to check for nil, but not sure about the outcome: you do want to have access to a logger, it's not an optional parameter, so, you should return an error if it's nil.

internal/coreinternal/attraction/attraction.go Outdated Show resolved Hide resolved
@jpkrohling jpkrohling force-pushed the attributesprocessor-auth-from-context branch from d9230ae to 42fa321 Compare April 29, 2022 12:55
@jpkrohling
Copy link
Member

PR rebased

@svrakitin
Copy link
Contributor Author

@jpkrohling Thanks.

@svrakitin
Copy link
Contributor Author

@jpkrohling What is left to get it merged?

@pmm-sumo pmm-sumo added the ready to merge Code review completed; ready to merge by maintainers label May 4, 2022
@pmm-sumo
Copy link
Contributor

pmm-sumo commented May 4, 2022

Juraci is now on parental leave :) But since we have 3 approvals (including two from approvers/contributors) and passing tests, I'm marking this as ready-to-merge

internal/coreinternal/attraction/attraction.go Outdated Show resolved Hide resolved
func NewAttrProc(settings *Settings) (*AttrProc, error) {
var attributeActions []attributeAction
func NewAttrProc(settings *Settings, logger *zap.Logger) (*AttrProc, error) {
if logger == nil {
Copy link
Member

Choose a reason for hiding this comment

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

I agree, this seems to be unrelated, consider to split a separate PR.

internal/coreinternal/attraction/attraction.go Outdated Show resolved Hide resolved
@bogdandrutu
Copy link
Member

@pmm-sumo there are lots of unrelated changes, and some random configurations for logger (why do we need sampling here and not in other places? add debug logs if too many, record metrics, etc.)

@bogdandrutu bogdandrutu removed the ready to merge Code review completed; ready to merge by maintainers label May 4, 2022
@svrakitin
Copy link
Contributor Author

@bogdandrutu There was a suggestion to log invalid atrribute types if they are returned by ServerAuthenticator: #9420 (comment)

I don’t care much about sampling and can drop it. It was taken from the suggestion in one of the comments above.

I will reduce this PR to changes I originally introduced and leave further changes to maintainers who have a better idea than me.

@bogdandrutu
Copy link
Member

@svrakitin it is not about "better idea than me", it is about keeping the PRs focus on what we want to implement :)

@pmm-sumo
Copy link
Contributor

pmm-sumo commented May 4, 2022

Good point @bogdandrutu, apologies for messing up with tagging and thanks for bringing this up.

On the sampled logger thing, I believe it stems from this comment. I mentioned sampled logging since this was something brought to my attention in the past (don't recall which PR but I can look it up for context).

In principle, I think that user should know that something is wrong and because of that debug logs are not a good fit. I also heard some comments that the collector is sometimes too quiet over what happens in the components and some users anticipate more logging. At the same time, we want to limit the impact of that log if happens frequently, hence (aggressive) sampled logger and warn level.

So we have two paths here:

  • always use debug level for such kind of logs
  • use sampled logger and move it to a common package, so other components could use it easily for potentially noisy logs

I was inclined towards the latter (in a separate PR). There are some components doing that already and I was aiming at doing the cleanup after this get merged. Before I open the issue wanted to check what is your preference @bogdandrutu

@svrakitin svrakitin force-pushed the attributesprocessor-auth-from-context branch from 42fa321 to a147333 Compare May 4, 2022 14:23
@svrakitin
Copy link
Contributor Author

I reduced this PR to the initial set of changes. Let's address how we warn users in a separate PR then.

@pmm-sumo pmm-sumo dismissed their stale review May 4, 2022 14:41

PR changed, re-review needed :)

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

This PR looks much better now, @pmm-sumo please re-approve since you are familiar, and add the label again

@pmm-sumo pmm-sumo added the ready to merge Code review completed; ready to merge by maintainers label May 4, 2022
@bogdandrutu bogdandrutu merged commit aca7b2f into open-telemetry:main May 5, 2022
djaglowski pushed a commit to djaglowski/opentelemetry-collector-contrib that referenced this pull request May 10, 2022
open-telemetry#9420)

Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Co-authored-by: Alex Boten <aboten@lightstep.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to merge Code review completed; ready to merge by maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Attributes processor from_context should provide access to AuthData attributes
5 participants