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.

Sign up for GitHub

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

Jump to bottom

xds: support built-in Stdout audit logger type #6298

Merged
merged 21 commits into from
May 25, 2023
Merged

xds: support built-in Stdout audit logger type #6298

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
4d8e4b7
Add test for building stdout logger
gtcooke94 May 18, 2023
f3b679c
Cleanup
gtcooke94 May 18, 2023
58b9e48
%s/steam/stream/
gtcooke94 May 18, 2023
599cb13
go mod tidy compat=1.17
gtcooke94 May 18, 2023
e5de42f
Add test with same name but generic config
gtcooke94 May 18, 2023
3f6f35a
mod tidy
gtcooke94 May 18, 2023
699a42f
vet
gtcooke94 May 18, 2023
218be79
mod tidy
gtcooke94 May 18, 2023
8d3c9c4
mod tidy
gtcooke94 May 18, 2023
f349cdc
mod tidy
gtcooke94 May 18, 2023
ed23d8f
Try different marshaler
gtcooke94 May 18, 2023
0861548
Address comment
gtcooke94 May 23, 2023
eb31885
Address comment
gtcooke94 May 23, 2023
32363cd
Cleanup test case
gtcooke94 May 23, 2023
5997a19
typo Stuct -> Struct
gtcooke94 May 24, 2023
ae08173
Address PR comments - cleanup getCustomConfig and testing types
gtcooke94 May 24, 2023
c283e73
unexport stdout logger
gtcooke94 May 24, 2023
2c689b1
Test cleanup
gtcooke94 May 24, 2023
58a309d
typo
gtcooke94 May 24, 2023
f719de2
simplify helper fn
gtcooke94 May 25, 2023
4cda2b3
use MarshalAny testutil
gtcooke94 May 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 7 additions & 5 deletions authz/audit/stdout/stdout_logger.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,8 @@ import (

var grpcLogger = grpclog.Component("authz-audit")

const Name = "stdout_logger"
Copy link
Member

Choose a reason for hiding this comment

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

Are all loggers going to be registered with a _logger suffix? Isn't this redundant? Is this standardized across languages or no?

Copy link
Contributor

Choose a reason for hiding this comment

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

While I don't have strong preference on whether to keep this suffix, we are using the same name in C++ and it will be the same across languages such that the same authz policy can work everywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was previously hardcoded here

I was just pulling it out to be an exported const so it could be looked up.

I'd be okay to change the name to stdout, what do you think @rockspore

Copy link
Member

Choose a reason for hiding this comment

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

Oh wait..should this just not even be in the registry at all? It seems like it's a built-in type that we support and not something that is supposed to be supported via the registry for generic loggers?

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 believe the intention with the built in types is that we place them in the registry for use -

grpc-go/authz/audit/stdout/stdout_logger.go

Lines 34 to 38 in a6e1acf

func init() {
audit.RegisterLoggerBuilder(&loggerBuilder{
goLogger: log.New(os.Stdout, "", 0),
})
}

@rockspore please check me here

Copy link
Contributor

@rockspore rockspore May 24, 2023 •
edited

Choose a reason for hiding this comment

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

I'd be okay to change the name to stdout, what do you think @rockspore

If there is no strong preference, I'm leaning towards keeping it as is so that we don't have to change what's already in C++ and the latest gRFC PR.

Oh wait..should this just not even be in the registry at all?

We use the same registry for built-in loggers. We just pre-register them by importing the pkg here. The registry API probably needs to prevent the built-in types from being overwritten.

Copy link
Member

Choose a reason for hiding this comment

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

We use the same registry for built-in loggers. We just pre-register them by importing the pkg here. The registry API probably needs to prevent the built-in types from being overwritten.

This doesn't sound right to me.

I think the built-in types should be hard-coded and not be present in the registry. IIUC the registry is for the custom types that users can implement. AFAICT there's no need to put the built-in types into the registry. It buys us nothing and seems to have some downsides.

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 an important but tangential-to-this-pr point to iron out.

@dfawley how would you feel about keeping this PR going as if the current behavior is the right behavior.
Then, we can resolve this separately, and if we change how the stdout logger is constructed we will update that in a separate PR.
As the audit logging is currently implemented, this is the correct way to do it.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, maybe this is fine. This is still pretty similar to our LB policy design this was based on. The difference here is that the two steps of converting from xds config to local config and then building are so close together that it seems unnecessary to have them be separate. But they're separate because we intend for them to be used through other pathways than xDS, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, we tried to stay similar to the LB policy for consistency

But they're separate because we intend for them to be used through other pathways than xDS, right?

Yes, it can come through here through NewStatic


func init() {
audit.RegisterLoggerBuilder(&loggerBuilder{
goLogger: log.New(os.Stdout, "", 0),
Expand All @@ -46,13 +48,13 @@ type event struct {
Timestamp string `json:"timestamp"` // Time when the audit event is logged via Log method
}

// logger implements the audit.Logger interface by logging to standard output.
type logger struct {
// Logger implements the audit.Logger interface by logging to standard output.
type Logger struct {
goLogger *log.Logger
}

// Log marshals the audit.Event to json and prints it to standard output.
func (l *logger) Log(event *audit.Event) {
func (l *Logger) Log(event *audit.Event) {
jsonContainer := map[string]interface{}{
"grpc_audit_log": convertEvent(event),
}
Expand All @@ -75,14 +77,14 @@ type loggerBuilder struct {
}

func (loggerBuilder) Name() string {
return "stdout_logger"
return Name
}

// Build returns a new instance of the stdout logger.
// Passed in configuration is ignored as the stdout logger does not
// expect any configuration to be provided.
func (lb *loggerBuilder) Build(audit.LoggerConfig) audit.Logger {
return &logger{
return &Logger{
goLogger: lb.goLogger,
}
}
Expand Down
2 changes: 1 addition & 1 deletion go.mod
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ require (
github.com/cespare/xxhash/v2 v2.2.0
github.com/cncf/udpa/go v0.0.0-20220112060539-c52dc94e7fbe
github.com/cncf/xds/go v0.0.0-20230310173818-32f1caf87195
github.com/envoyproxy/go-control-plane v0.11.1-0.20230406144219-ba92d50b6596
github.com/envoyproxy/go-control-plane v0.11.1-0.20230517004634-d1c5e72e4c41
github.com/golang/glog v1.1.0
github.com/golang/protobuf v1.5.3
github.com/google/go-cmp v0.5.9
Expand Down