policy audit logging initialization query

[Rameshreddy Mudhireddy]

Hi grpc-team,

we support hitless restart of the grpc service for any configuration changes and policy audit logging interface has the following comment.

// Registers an audit logger factory. This should only be called during
 // initialization.
 void RegisterAuditLoggerFactory(std::unique_ptr<AuditLoggerFactory> factory);

Hitless restart of the service for any changes in the policy audit logging name is running into an assert and requires a process restart.

Init sequence:

RegisterAuditLoggerFactory(...)

server_data = new ::pi::server::ServerData();
server_data->builder.experimental().SetAuthorizationPolicyProvider(provider);

server_data->builder.BuildAndStart();

shutdown sequence:

server_data->server->Shutdown(<5 sec deadline>);

delete server_data;

Issue:

E0706 17:12:26.951911933  385451 audit_logging.cc:57]                  ASSERTION FAILED: registry->logger_factories_map_.emplace(name, std::move(factory)).second

Is there any way to avoid process restart for any of the  policy audit logging config changes? Appreciate your input.

Thank you,

Ramesh

[Luwei Ge]

Hi Ramesh,

I am not sure if I fully understand your problem. Are you restarting the gRPC server within your process? If so, I think you need to call RegisterAuditLoggerFactory again, if you didn't.

Best,

Luwei

[Rameshreddy Mudhireddy]

Hi Luwei,

"Are you restarting the gRPC server within your process?"

Yes

"need to call RegisterAuditLoggerFactory again"

Yes, did call RegisterAuditLoggerFactory again and it is running into the above mentioned grpc assert.

Thank you for your attention on this.

[Rameshreddy Mudhireddy]

Test case is:

If the server is setup with the following config:

 "audit_logging_options": {
      "audit_condition": "ON_DENY_AND_ALLOW",
      "audit_loggers": [
         {
            "name": "foo"
         }
      ]
   }

Any subsequent grpc service restarts will run into assert. That can be worked-around by applications by maintaining last registered "name" handle and only call into it if there is any update but that is not ideal. If the config is changing to   

 "audit_logging_options": {
      "audit_condition": "ON_DENY",
      "audit_loggers": [
         {
            "name": "bar"
         }
      ]
   }

then there is no way to avoid the assert. May be I am missing something?

Thanks,

Ramesh 

[Luwei Ge]

The intent of the Register... API is that all audit loggers that may be used should have been registered from the very beginning, because custom loggers can possibly be custom implementations which need to be compiled and built into the application binary. So I think the correct way to run your test is to register both "foo" and "bar" at the beginning of all test cases. Let me know if there is any problem with that.

Best,

Luwei

[Rameshreddy Mudhireddy]

Hi Luwei,

"all audit loggers that may be used should have been registered from the very beginning" is very rigid, also it is not possible to know beforehand because it comes from customer defined "policy.json" input and it doesn't play well with the "hitless restart of the grpc service for any configuration changes" design we have. Any possible work-around to deal with this is appreciated.

P.S: sorry for delayed response (was on Vacation)

Regards

Ramesh

[Rameshreddy Mudhireddy]

fyi, filed https://github.com/grpc/grpc/issues/40576